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Chapter 1 


Introduction 


Recent verification research at NASA Langley has emphasized theorem proving over the 
domain of reals [3, 4, 7], with PVS [13, 16] serving as the primary proof tool. Efforts in 
this area have met with some difficulties, prompting a search for improved techniques for 
interactive proving. Significant productivity gains will be needed to fully realize our formal 
methods goals. 

For arithmetic reasoning, PVS relies on decision procedures augmented with automatic 
rewriting. When a conjecture fails to yield to these tools, which often happens with nonlin- 
ear arithmetic, considerable interactive work may be required to complete the proof. Large 
productivity variances are the result. 

SRI continues to increase the degree of automation in PVS. In particular, decision 
procedures for real arithmetic are a planned future enhancement. We look forward to these 
improvements. Nevertheless, there will always be a point where the automation runs out. 
When that point is reached, the tactic-based 1 techniques of this report can be applied to 
good effect. Moreover, the basic approach is general enough to work for provers other than 
PVS. 

We have constructed a prototype implementation of an algebraic simplification kit using 
the PVS prover’s strategy mechanism. Called Manip, this package serves both as a useful 
adjunct to the prover as well as a proof of concept for similar packages. Adapting the strate- 
gies to other mathematical domains should yield benefits with only a modest development 
effort. 

1.1 Motivation 

Consider the following lemma for reasoning about trigonometric approximations: 

0 < a < tt/2 D |T„(o)| > 2 |T n +i(o)| (1.1) 

*In PVS nomenclature, a rule is an atomic prover command while a strategy expands into one or more 
atomic steps. A defined rule is defined as a strategy but invoked as an atomic step. For our purposes, we 
regard the terms “tactic,” “strategy” and “defined rule” as roughly synonymous. 
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("" (SKOSIMP*) 

(REWRITE "sin_term_next") 

(RECIP-MULT! (! 1 R (-> "abs") 1)) 
(APPLY (REPEAT (REWRITE "abs.mult") ) ) 
(PERMUTE-MULT 1 R 3 R) 

(OP-IDENT 1 L 1+) 

(CANCEL 1) 

(("1" (EXPAND "abs") 

(ASSERT) 

(PERMUTE-MULT 1 R 2 R) 
(CROSS-MULT 1) 

(MULT-INEQ -2 -2) 

(TYPEPRED "PI") 

(EXPAND "PI_ub") 

(MULT-INEQ -4 -4) 

(ASSERT)) 

("2" (USE "sin_term_noiizero") 

(GRIND NIL : REWRITES ("abs"))))) 


strategy 

strategy 

strategy 

strategy 


strategy 

strategy 

strategy 


strategy 


Figure 1.1: Proof steps for lemma (1.1) using manipulation strategies 
where 7) (a) is the ith term in the power series expansion of the sine function: 

OO 

sin (a) = ]T(— irV 2 *-7(2i - 1)! . (1.2) 

i — 1 

Using only built-in rules, the proof of (1.1) required 68 steps. A common technique in 
such proofs is to use the case rule to force a case split on the equality of two subexpressions 
in the sequent, such as: 

(CASE "all * all * (2 * 2) = (2 * all) * (2 * all)") 

Although not peculiar to PVS, this need to construct equivalent expressions and bring them 
to the prover’s attention is an awkward way to achieve simplification. It leads to a tedious 
style of proof that tries the patience of most users. 

In contrast, by using our techniques we were able to prove the lemma more naturally 
in 18 steps, 8 of which are strategies from our package, as shown in Figure 1.1. Unlike 
the case-split technique, none of the steps contains excerpts from the sequent. This proof 
represents one of the better examples of improvement from the use of our strategies. While 
many proofs will experience a less dramatic reduction in complexity, the results have been 
encouraging thus far. 

1.2 Objectives 

Mechanical theorem proving is often thought, for certain domains of application at least, 
to require too much effort for the benefits obtained. Our overall objective is to mitigate 
this situation for the domain of real arithmetic, at a minimum, so that theorem proving 
might become more widely applied in engineering. In the process, we have pursued several 
subordinate objectives. 
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• Make the prover interface more approachable. It is desirable to enable those hav- 
ing mathematical skill but not mechanical proving experience to become productive 
quickly. Most (potential) users are not logicians or theoretical computer scientists. 
They are unlikely to embrace a proof approach that entails fine tuning libraries of 
rewrite rules, for instance. 

• Trade proof performance/ efficiency for predictability. Giving users interactive facilities 
that mimic manual mathematical techniques allows them to make progress, despite 
the prospect of producing larger than necessary proofs. We seek a human-machine 
collaboration style that is less likely to be viewed as frustrating or futile. 

• Support an effective theorem-proving division of labor. It should be possible to capture 
the knowledge of more experienced prover users in a form that helps less experienced 
users prove theorems routinely. We emphasize tactic-based techniques as a way to 
codify this knowledge. 

• Explore approaches that are customizable for different domains. After converging on a 
useful package, its structure should be adaptable to other mathematical domains with 
high reuse potential. We will develop some components that need not be adapted but 
can simply be used as is. 

The next chapter outlines key aspects of our approach for achieving these objectives. 
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Chapter 2 


Enhanced 


Deduction Approach 


User-defined proof strategies can be seen as a type of “deductive middleware.” Systematic 
strategy development for various domains could improve user productivity considerably. 
This chapter proposes a general scheme for structuring and implementing strategies in 
PVS along with supporting features. Chapter 3 sketches a particular set of strategies for 
manipulating arithmetic expressions. 

2.1 Overall Architecture 

We propose an integration of several elements to arrive at a tactic-based deduction archi- 
tecture for user enhancements to PVS. 

1. Domain-specific proof strategies. Common reasoning domains, such as nonlinear real 
arithmetic, provide natural targets for increasing automation. Extracting terms from 
sequents using suitable access facilities is vital for implementing strategies that do 
meaningful work. 

2. Extended expression language. Inputs to existing prover rules are primarily formula 
numbers and expressions in the PVS language. For greater effectiveness, we provide 
users with a language for specifying subexpressions by location reference and pattern 
matching. 

3. Higher-order strategies with substitution. Strategies that apply other proof rules offer 
the usual convenience of functional programming. Adding substitutions based on the 
evaluation of extended expressions yields a more powerful way to construct and apply 
rules dynamically. 

4. User-interface utilities. To improve command line invocation of proof rules as well 
as offer various proof maintenance functions, a set of Emacs-based interface enhance- 
ments is included. 

5. Prelude extension libraries. The PVS prelude holds built-in core theories. Strategies 
use prelude lemmas but often need additional facts. PVS’s prelude extension feature 
adds such theorems in a manner transparent to the user. 
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The complementary nature of these elements gives the integrated deduction architecture 
its effectiveness. Note that only elements 1 and 5 are domain specific; the others are quite 
generic. 

Several benefits accrue from this architecture. 

• User interaction is more natural, less laborious and occurs at a higher level of abstrac- 
tion. 

• Many manipulations apply lemmas from the prelude or its extensions. Strategies 
enable proving without explicit knowledge of these lemmas. 

• The brittleness of proofs is reduced by avoiding the inclusion of expressions from the 
current sequent in stored proof steps. 

• Proving becomes more approachable for those with mathematical sophistication but 
little experience using mechanical provers. 

We envision some features as being more useful during later stages of proof development, 
especially when finalizing a proof to make the permanent version more robust. During the 
early stages, it is easier to work directly with actual expressions. Once the outline of a proof 
is firm, extended expression features can be introduced to abstract away excessive detail. 

2.2 Design Considerations for Domain-Specific Strategies 

User input to the PVS prover is via Lisp s-expressions. Internally the prover uses CLOS 
(Common Lisp Object System) classes to represent expressions and other data. PVS pro- 
vides macros for creating user-defined proof rules, which may include fragments of Lisp code 
to compute new values for invoking other rules. 

We postulate the following guidelines for developing a strategy package. 

1. Introduce domain-relevant arguments. For arithmetic strategies, a user typically needs 
to specify values such as the side of a relation (L, R), the sign of a term (+, -), and 
term numbers. Variations on the conventions of existing prover input handle these 
cases nicely. 

2. Augment term access functions. Besides the access functions provided by the prover, 
additional ones may be needed to extract relevant values, e.g., the *th term of an 
additive expression. A modest set of access functions suffices for working with common 
language elements, such as arithmetic terms. 

3. Use text-based expression construction. A proper implementation style would be to 
use object constructors to create new expression values. This requires knowledge of 
a large interface. Instead, it is adequate for most uses to exploit the objects’ print 
methods and construct the desired expressions in textual form, which can then be 
supplied as arguments to other proof rules. 

4. Use Lisp-based symbolic construction. To build final proof rules for invocation, the 
standard Lisp techniques for s-expression construction, such as backquote expressions, 
work well. 
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(DEFSTEP has-sign (term &optional (sign +) (try-just nil)) 

(LET ( (term-expr (ee-obj -or-string (car (eval-ext-expr term)))) 
(relation (case sign 

((+) ’» ((-) ’<) (( 0 ) ’=) 

((0+) ’>=) ((0-) ’<=) ((+-) ’/=) (t ’»)) 

(case-step ‘(CASE , (format nil "~A “A 0" term-expr relation))) 
(step-list 

(list ’(SKIP) (try-justif ication ’has-sign try-just)))) 

(SPREAD case-step step-list)) 

"Try claiming that a TERM has the designated SIGN (relationship to 0) . 
Symbols for SIGN are (+ - 0 0+ 0- +-) , which have meanings positive, 
negative, zero, nonnegative, nonpositive, and nonzero. Proof of the 
justification step can be tried or deferred. Use TRY- JUST to supply 
a step for the justification proof or T for the default rule (GRIND)." 

"“"/.Claiming the selected term has the designated sign") 


Figure 2.1: Sample strategy built using PVS defstep macro 

5. Incorporate prelude extensions as needed. When prelude lemmas are inadequate to 
support the desired deductions, a few judiciously crafted lemmas, custom designed for 
specific strategies, can be added invisibly. 

Applications of items 1-4 are demonstrated in the simple example of Figure 2.1. Most 
strategies are rather more complicated than this example, often requiring the services of 
additional Lisp functions and intermediate helper strategies. 

In the step definition of Figure 2.1, a LET strategy is used to compute intermediate 
Lisp objects. These end up being incorporated into the final step, an invocation of SPREAD, 
which is used to manage proof steps for a case split. The argument term is allowed to 
be an extended expression (see Chapter 4). The access function eval-ext-expr evalu- 
ates it with respect to the current sequent and returns a structured object having several 
components. Based on the sign argument, a PVS relation symbol is selected for use in 
generating the CASE step. The backquote expression computes this step as a list object 
such as (CASE "x!l > 0"). 

Two follow-up steps need to be specified for how to proceed after the case split. For 
has-sign, the first branch does nothing but await further user direction, as indicated by the 
step (SKIP). The other branch represents a proof attempt for the justification of the claim. 
Given the user’s instructions in argument try-just, the Lisp function try-justification 
derives a suitable prover step, including backtracking in case the proof attempt fails to fully 
discharge the branch. A typical generated step would look like the following. 

(TRY (THEN (GRIND) (FAIL)) 

(SKIP) 

(SKIP-MSG "Justification proof for HAS-SIGN using (GRIND) 
is unfinished; undoing proof attempt.")) 

Once all these elements have been computed, the final outcome of has-sign is a proof 
step written in terms of SPREAD, such as the following. 


(SPREAD (CASE "x!l > 0") 
((SKIP) 
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(TRY (THEN (GRIND) (FAIL)) 

(SKIP) 

(SKIP-MSG "Justification proof for HAS-SIGN using (GRIND) 
is unfinished; undoing proof attempt.")))) 


2.3 Strategy Inputs 

Before describing the actual strategies, we sketch a few noteworthy features and capabilities 
that apply throughout the package. Most are concerned with the formulation of arguments 
supplied during strategy invocation. 

• In PVS nomenclature, a rule is an atomic prover command and a strategy is a com- 
mand that expands into one or more atomic steps. A defined rule is a command 
defined as a strategy but invoked as an atomic step. What we loosely call strategies 
in this package are defined rules when invoked in the normal manner. The “$” forms 
are the nonatomic strategy forms, which can be used to improve diagnostic infor- 
mation by showing the expansion into core PVS rules. For instance, using cancel$ 
instead of cancel spawns an expanded proof. 

• Many of the lemmas in prelude theory real_props are used by the arithmetic strate- 
gies. Additional lemmas are needed to implement certain operations. The PVS 
prelude-extension feature is the mechanism for integrating these new lemmas with- 
out requiring any action on the user’s part. Extension theories and their lemmas are 
automatically visible within the prover. 

A theory called extra_real_props extends the prelude with a set of real number 
properties. These lemmas are applied as needed by the strategies, but also may be 
applied directly by the user if desired. As strategies are added to the package, this 
theory will be extended further to support new proof tactics. 

• As is true for the built-in prover commands, wherever a formula number is called for, 
a formula label (symbol) may be supplied instead of a number. The special symbols 
+, — and * are also available with their usual meanings as lists of formula numbers. 
A special form is provided to construct the complement of a set of formula numbers. 
Using the form (* nl ... nk) wherever formula numbers are required indicates the 
list of all formulas minus ni, . . . , n^. Two additional forms, (-* . . . ) and (+~ . . . ) , 
yield the complements of antecedent and consequent formula lists. 

• Many of the arithmetic strategies accept term numbers as arguments, which are speci- 
fied in a manner analogous to formula numbers. A term’s position within its enclosing 
expression determines its term number value. Rules for counting terms are based on 
the arithmetic operators involved. Term numbers are expressed as integers, with term 
1 designating the first (left-most) term. The special symbol * is also available to de- 
note the list of all terms in an expression. Negative term numbers allow indexing from 
right to left, that is, -1 selects term n, -2 selects term n — 1, etc. The special form 
(~ nl ... nk) indicates all term numbers except m, . . . , n^. 
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• The prover has many commands that allow a user to specify PVS expressions as 
arguments. Such expressions take the form of a literal string such as “2 * PI * a ! 1” . 
We have found it useful to extend this capability and allow richer forms of expressions. 
Collectively these are called extended expression specifications (Chapter 4). For now 
we note that all strategies in this package that call for arguments in the form of terms 
or expressions may be supplied an extended expression as well as the familiar text 
string form. 

• Extended expressions also collect formula number data whenever possible. Pack- 
age strategies accept extended expressions wherever formula numbers are required. 
Numeric values are extracted from expression descriptors instead of text string com- 
ponents. 

• Several strategies are provided in two variants to accommodate different argument 
types. One variant, which typically accepts arguments based on formula numbers, 
suffices for simple but common uses. The other variant, which accepts arguments 
based on a subset of extended expressions called location references (Section 4.2), 
can support more complicated uses. The second variant is distinguished by the ‘ ! ’ 
character at the end of its name. 

• Proof branching is generated by some strategies where justification cases arise. Justifi- 
cation proofs may be attempted by supplying a non-nil value for the optional argument 
try-just, which may be either a proof step or the value t to indicate the step (grind). 
In either case, if the justification branch is not proved completely, the proof state for 
that branch will be rolled back so the user can make a fresh attempt. 

• When we speak of inequalities in the strategy descriptions, we refer to relations from 
the set {<, <, >, >}. The ^ operator (/=) is not included because PVS normally elim- 
inates such formulas by negating and moving them to the other side of the turnstile. 
Any occurrences of /= may be removed by using low-level prover commands such as 
(prop) and (ground). 
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Chapter 3 

Algebraic Manipulation Strategies 


This chapter describes a set of PVS prover strategies for manipulating arithmetic expressions 
and performing other detailed proving steps. It includes strategies helpful for proving 
formulas containing nonlinear arithmetic and similar expressions where PVS has limited 
automation. It is important to emphasize that these strategies might not be suitable as 
first-choice tools. Often it is preferable to try the more automatic prover features first, such 
as decision procedures, automatic rewriting, and muscular rules like (grind), then consider 
using these manipulations only if the other features fail. When proving with highly complex 
expressions, however, the automatic prover commands might take too long to be useful. In 
such cases, the more deliberate steps available from these strategies might be preferable. 

For those manipulation strategies that require explicit terms as arguments, the terms 
can be specified using either text strings in the normal manner, or the extended expressions 
of Chapter 4, or the extensions to the Emacs PVS prover helps (TAB shortcuts) described 
in Chapter 6. Tables 3.1 and 3.2 list the various manipulation strategies provided along 
with their formal argument lists. Additional package details are available in the user’s 
manual [6]. 

3.1 Simple Arithmetic Strategies 

This group of strategies performs common algebraic manipulations that normally are not 
needed if your formulas fall within the domain of the linear arithmetic decision procedures 
or the rewrite rules of prelude theory real_props. Auto-rewriting with real .props is often 
powerful enough to prove many goals when combined with grind. Sometimes, however, it 
leads to excessive or unbounded rewriting. In such cases, more deliberate steps need to be 
taken. 

Following are descriptions of the strategies and their signatures (formal argument lists). 
Invoking a strategy from the prover command line requires surrounding it in parentheses 
when typed, as is usually done. Invoking one using the TAB-z method of Chapter 6 will 
cause you to be prompted for each argument using the formal argument names shown. 


swap Ihs operator rhs feoptional (infix? T) 


[Strategy] 
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Table 3.1: Summary of manipulation strategies. 


Syntax Function 

(swap lhs operator rhs &opt (infix? T)) 

(swap! expr-loc) 

(group terml operator term2 term3 
&opt (side L) (infix? T)) 

(group! expr-loc &opt (side L)) 

(swap-group terml operator term2 term3 
&opt (side L) (infix? T)) 

(swap-group! expr-loc &opt (side L)) 

(swap-rel &rest fnums) 

(equate lhs rhs &opt (try-just nil)) 

(has-sign term &opt 

(sign +) (try-just nil)) 

(mult-by fnums term &opt (sign +)) 

(div-by fnums term &opt (sign +)) 

(split-ineq fnum &opt (replace? nil)) 

(flip-ineq fnums &opt (hide? T)) 

(show-parens &opt (fnums *)) 

(move-terms fnum side Move additive terms to other side 

&opt (term-mams *)) 

(isolate fnum side term-num) Move all but one term 

(isolate-replace fnum side term-num Isolate then replace with equation 

&opt (targets *)) 

(cancel &opt (fnums *) (sign nil)) Cancel terms from both sides 

(cancel-terms &opt (fnums *) (end L) Cancel speculatively & defer proof 

(sign nil) (try-just nil)) 

(op-ident fnum &opt Apply operator identity to rewrite 

(side L) (operation *1)) expression 

(op-ident! expr-loc &opt (operation *1)) 

(cross-mult &opt (fnums *)) Multiply both sides by denom. 

(cross-add &opt (fnums *)) Add subtrahend to both sides 

(factor fnums &opt (side *) Extract common multiplicative factors 

(term-nums *) (id? nil)) from additive terms given 

(factor! expr-loc &opt 

(term-nums *) (id? nil)) 

(transf orm-both fnum transform Apply transform to both 

&opt (swap nil) (try-just nil)) sides of formula 


X O y = ^ y OX 

L: X O {y o z) =>- {x O y) o z 
R: (x O y) o Z => X O (y o z) 

L: x o (y o z) y o (x o z) 

R: (x O y) o Z => (x O z) O y 

Swap sides and reverse relations 
. . . lhs . . . . . . rhs . . . 

Claims term has sign indicated 

Multiply both sides by term 
Divide both sides by term 
Split < (>) into < (>) and = cases 
Negate and move inequalities 
Show fully parenthesized formulas 
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Table 3.2: Summary of manipulation strategies (continued). 


Syntax Function 


(permute-mult fnums &opt (side R) 

(term-nums 2) (end L)) 
(permute-mult ! expr-loc &opt 

(term-nums 2) (end L)) 
(name-mult name fnum side 
&opt (term-nums *)) 

(name-mult ! name expr-loc 
&opt (term-nums *)) 

(recip-mult fnums side) 

(recip-mult! expr-loc) 

(isolate-mult fnum &opt (side L) 

(term-num 1) (sign +)) 
(mult-eq rel-fnum eq-fnum 
&opt (sign +)) 

(mult-ineq fnuml fnum2 

&opt (signs (+ +))) 

(mult-cases fnum 

&opt (abs? nil) (mult-op *1)) 
(mult-extract name fnum &opt 

(side *) (term-nums *)) 
(mult-extract! name expr-loc 

&opt (term-nums *)) 


Rearrange factors in a product 


Select factors, assign name to 
their product, then replace 

x/d => x * (1/d) 

Select a factor and divide both 
both sides to isolate factor 
Multiply sides of relation by 
sides of equality 
Multiply sides of inequality by 
sides of another inequality 
Generate case analyses for products 

Extract selected terms, name 

replace them, then simplify 


swap ! expr-loc [Strategy] 

The swap strategy tries exchanging terms in commutative expressions. It replaces each 
applicable expression according to the scheme x o y =$■ y ox. All occurrences of x o y in the 
sequent are replaced. Infix operators are normally expected, but prefix function application 
is also accommodated by setting the infix? argument to nil. In fact, any binary function 
may be used provided its commutativity can be established. 

In the ! variant, a subset of extended expressions called location references (Section 4.2) 
may be used to supply the expr-loc argument. The referenced expression must be an ap- 
plication of a commutative function or operator. The strategy determines whether it is an 
infix or a prefix application. Multiple expression locations may result from a single expr-loc 
argument. Only the first will be processed. 

Usage: (swap "all" * "(x!l - 2) ") commutes the two factors in the multiplicative 
expression a ! 1 * (x ! 1 - 2). If formula 3 is min (a! 1 , x!l) > 0, then (swap! (! 3 L)) 
rewrites the formula to min(x ! 1 , a ! 1) > 0. 
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group terml operator term2 term3 feoptional ( side L) (infix? T) [Strategy] 

group! expr-loc &optional (side L) [Strategy] 

group tries rearranging terms in associative expressions. It replaces each applicable expres- 
sion according to one of two schemes: 

L : X O (y o z) =>■ (x O y) o z, R : (x O y) o Z =£- X O (y o z) 

The ! variant allows suitable expressions to be indicated by location references. 

Usage: (group "all" * "x!l" "u!l" R) changes the expression (a! 1 * x!l) * u!l 

so it associates to the right. 


swap-group term.l operator term2 term3 feoptional (side L) (infix? T) [Strategy] 

swap-group! expr-loc feoptional (side L) [ Strategy ] 

The previous two strategies are combined to replace according to the schemes: 

L : x o (y o z) ==>■ y o (x o z). R : (x o y) o z =$■ (x o z) o y 

This might be used to “lift” a middle term out where it can be more accessible to lemmas 
and rewrite rules. The ! variant allows suitable expressions to be indicated by location 
references. 

Usage: (swap-group "a!l" * "(x!l - 2)" "sq(u!l)") moves the middle term to 
the left. 

swap-rel ferest fnums [Strategy] 

Relational formulas may have their two sides swapped using this strategy, with the direction 
of any inequality operators being reversed. Normally this type of transformation is unnec- 
essary. It might be useful in writing higher level strategies, however, where it can simplify 
matters to assume that the relation is always less-than, for example. In other situations it 
may be used to move preferred terms left so that rewrites are tried first on the chosen side. 

equate Ihs rhs &optional (try-just nil) [Strategy] 

With equate a user can claim an equality between expressions and have rhs replace Ihs. 
If the optional argument try-just is non-nil, it will be interpreted as a prover command 
to invoke for proving the justification, i.e., for proving Ihs = rhs. As a special case, the 
value “t” may be given to apply (grind) in the justification step. Although the effect of 
equate can be achieved using the prover rule case-replace, equate obviates the explicit 
construction of an equality expression and offers more convenience when used with the 
Emacs TAB-z feature or the extended expression feature. 

Usage: (equate "(x!l - 2)" "a!l" (assert) ) replaces (x ! 1 - 2) by a! 1, then ap- 
plies (assert) to try to prove the equality holds. 

has-sign term, feoptional (sign +) ( try-just nil) [Strategy] 

Often it is desirable to claim that a term has a certain sign or other relationship to zero. 
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has-sign allows the user to claim that term has a designated property, where sign can be 
one of six symbols with meaning as follows: 

+ - 0 0 + 0 - +- 

x > 0 x < 0 £ = 0 x > 0 x < 0 x 7^ 0 

Proof of the justification step can be tried or deferred as indicated by try- just. 

Usage: (has-sign "sin(phi!l + 2*PI) - sin(phi!l)" 0 T) claims an expression 
has value zero and tries to prove it using (grind). 


mult-by fnums term ■ &optional (sign +) [Strategy] 

Both sides of a relational formula may be multiplied by a common factor using mult-by. 
For inequality relations, when the factor is known to be positive or negative, use + or — as 
the sign argument. Otherwise, use *, which introduces a conditional expression to handle 
the two cases in the same manner as cross-mult (see page 16). No sign argument is needed 
for equalities. 

The built-in prover command both-sides offers a way to achieve similar effects. Strat- 
egy mult-by, however, provides the means to specify a term’s polarity and perform a 
case split accordingly, which usually proves the justification branch automatically. With 
both-sides, it is often necessary to prove the justification explicitly. Moreover, when 
multiplying an inequality by a negative term, it will not formulate the desired proposition. 

Usage: (mult-by 2 "y!l" -) multiplies both sides of formula 2 by y ! 1, which is de- 
clared to be negative, causing the two sides of the formula to be swapped. 

div-by fnums term &optional (sign +) [Strategy] 

Both sides of a relational formula may be divided by a common divisor using div-by. For 
inequality relations, when the divisor is known to be positive or negative, use + or — as the 
sign argument. Otherwise, use *, which introduces a conditional expression to handle the 
two cases in the same manner as mult-by. No sign argument is needed for equalities. 

Usage: (div-by 2 "sq(y!l)") divides both sides of formula 2 by sq(y!l), which is 
assumed to be positive. 

split-ineq fnum &optional (replace? nil) [Strategy] 

Given that fnum is a nonstrict, antecedent inequality (<= or >=), split-ineq forces the 
sequent to split into two cases, e.g., an equal-to and a less-than case. It also works if fnum 
is a strict consequent inequality. Simplification using (assert) is applied after splitting. 
The equality may be optionally used for replacement by supplying the direction LR or RL 
for the replace? argument. 

Usage: If formula 2 is x! 1 > y! 1, then (split-ineq 2 RL) causes a case split on the 
expression “x ! 1 = y ! 1” and performs the replacement of x ! 1 for y ! 1 in the equality branch. 

f lip-ineq fnums feoptional (hide? T) [Strategy] 

One property of the prover’s sequent representation is that a sequent having antecedent 
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(consequent) formula P is equivalent to one having ->P as a consequent (antecedent) for- 
mula. The prover automatically makes use of this equivalence, even though ->P does not 
explicitly appear in the sequent. In the case of an inequality relation, its negation is itself 
another inequality. Occasionally a user might prefer one inequality form and location over 
another. Adjustments along these lines may be accomplished using f lip-ineq. 

For fnums that are inequality relations, flip-ineq negates the inequalities and moves 
the negated formulas by exchanging between antecedents and consequents. Conjunctions 
and disjunctions of inequalities are also accepted, causing each conjunct or disjunct to be 
negated in an application of De Morgan’s law. If hide? is set to nil, the original formulas 
are left intact; otherwise, they are hidden. 

Usage: If formula 2 is “x!l > y ! 1” , then (flip-ineq 2) causes “x!l <= y!l” to be 
added as formula -1. If formula -3 is the disjunction “x ! 1 > 9 OR y ! 1 < 6 OR z!l >= 3”, 
then (flip-ineq -3 nil) adds “x!l <= 9 AND y ! 1 >= 6 AND z!l < 3” as a new for- 
mula 1 and retains the original formula -3. 


show-parens &optional ( fnums *) [Strategy] 

Occasionally it is useful to see how terms are associated in a complex expression. The full 
parenthesization of a formula’s term structure may be displayed using show-parens. Its 
behavior is incomplete; it does not handle all features of PVS syntax, only the common 
ones such as infix and prefix function application. PVS 3.0 is supposed to include a way to 
display parenthesization, so this strategy is only a stopgap measure until 3.0 arrives. 

3.2 Intermediate Arithmetic Strategies 

This second group of arithmetic strategies tries to carry out common manipulations without 
specifying the actual terms from the sequent. This is generally desirable to prevent detailed 
expressions from being saved with the proof step. Avoiding such cases can lead to more 
robust proofs that require less updating when lemmas or theories are changed. 

move-terms fnum side &optional (term-nums *) [Strategy] 

With move-terms a user can move a set of additive terms numbered term-nums in relational 
formula fnum from side (L or R) to the other side, adding or subtracting individual terms 
from both sides as needed, term-nums can be specified in a manner similar to the way 
formula numbers are presented to the prover. Either a list or a single number may be 
provided, as well as the symbol “*” to denote all terms on the chosen side. Note that 
parentheses and associative grouping are ignored for purposes of assigning term numbers, 
e.g., term 2 in "x + (y + z)" is y, not y + z. 

Usage: (move-terms 3 L (2 4)) moves terms 2 and 4 from the left to the right side 
of formula 3. 

isolate fnum side term.-num [Strategy] 

A special case of move-terms is offered by isolate, which moves all additive terms except 
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that numbered term-num from side (L or R) to the other side. If fnurn is an equality, 
the effect is the same as solving for an additive term. Isolate is equivalent to the form 
(move-terms fnurn side (~ term-num)) (refer to term-number discussion on page 7). 
Usage: (isolate 1 R 3) moves all right-side terms except number 3 to the left. 


isolate-replace fnurn side term-num &optional (targets *) [ Strategy ] 

A further special case is when isolate is applied to an antecedent equality. The resulting 
equality may be used to replace the isolated term in targets, after which the equality is 
hidden. 

Usage: (isolate-replace 1 L 3 +) solves for left-side term 3 and uses the resulting 
equality for replacement in the consequent formulas. 


cancel &optional ( fnums *) ( sign nil) [Strategy] 

Cancellation is available through the automatic rewrites of prelude theory real props. Of- 
ten this rewriting does more than desired, however, and at other times misses opportunities 
for cancellation. For these reasons, we provide a more focused operation in cancel. When 
the top-level operator on both sides of a relation in fnums is the same operator drawn from 
the set {+,—,*,/}, cancel tries to eliminate common terms using a small set of rewrite 
rules and possible case splitting. No other simplification is attempted. 

Cancellation is possible when fnurn has one of two forms: 

x o y R x o z, y o x R z o x 

The types allowed for x , y , z depend on the relation and arithmetic operator involved. In the 
default case, when sign is NIL, x is assumed to be (non)positive or (non) negative as needed 
for the appropriate rewrite rules to apply. Otherwise, an explicit sign can be supplied to 
force a case split so the rules will apply. If sign is + or -, x is claimed to be strictly positive 
or negative. If sign is 0+ or 0-, x is claimed to be nonnegative or nonpositive. If sign is *, 
x is assumed to be an arbitrary real and a three-way case split is used. No sign argument 
is needed for equality relations. 

At times, unproved cases requiring user attention are split off. Such cases can result 
when the canceled term does not match the sign argument or when cancellation is invalid for 
other reasons. A further caveat is that cancel only works with top-level operations. This 
means that (x * y) * z = (x * a) * b will not yield to cancel, nor will it be simplified 
through real_props automatic rewriting. In such cases, use the cancel-terms strategy 
(immediately following) or do some rearranging of the formula before attempting cancel. 

Usage: (cancel 3 0-) tries to cancel from both sides of formula 3 after first splitting 
on the assumption that the common term is nonpositive. 


cancel-terms &optional (fnurn, s *) (end L) (sign nil) (try-just nil) [Strategy] 

Often it is desirable to cancel nonidentical terms speculatively. This capability is offered 
through cancel-terms, which splits into cases on the assumption that both left-most or 
right-most terms in a relational formula are equal. The user can specify at which end (L 
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or R) of a chain of similar infix applications to look for the allegedly common term. Asso- 
ciative groupings are ignored when identifying the end term. The operator is considered 
equivalent to ‘+’ for this purpose. On the other hand, only the outer-most application in a 
chain of ‘/’-separated terms is recognized. 

As an example, suppose that formula 2 is x *y*z>a*b*c. (cancel-terms 2) 
will first introduce a case split on the condition x = a. Then it will use this equality to 
reduce formula 2toy*z>b*c. On the other proof branch, the user will have to 
establish x = a. 

For inequalities, the sign argument can be used to indicate term polarity as in cancel. In 
addition, an automatic proof attempt of the terms’ equality can be triggered using try-just. 

Usage: (cancel-terms 3 L + T) tries to cancel the left-most term from both sides 
of formula 3 after first splitting on the assumption that the positive terms are equal. An 
automatic attempt to prove their equality using (grind) is performed. 


op-ident fnum &optional ( side L) ( operation *1) [Strategy] 

op-ident ! expr-loc &optional (operation *1) [Strategy] 

The cancellation strategies do not handle any “one-sided” cases, e.g., a relation of the form 
x R x * y. Rewriting with real_props likewise offers no benefit. We provide op-ident 
to perform the setup for such cancellations and similar operations. The operator identity 
given by operation is used to rewrite the expression found on side of formula fnum. 

In the ! variant, a subset of extended expressions called location references is provided 
for supplying the expr-loc argument (Section 4.2). Multiple expression locations may result 
from a single expr-loc argument. Each will be processed separately. 

Currently, the following operations are available using these designated symbols: 

z+ +z -z 1* *1 /I 

0 T x x + 0 x — 0 l*x x*l x/l 

Note that symbols using ‘z’ rather than ‘0’ are used because +0 and -0 are treated by Lisp 
as the number 0 rather than as symbols. 

Usage: (op-ident -2 L 1*) rewrites formula -2 from b ! 1 < all * b ! 1 to the equiv- 
alent formula 1 * b ! 1 < all * b ! 1 . The form (op-ident! (! -2 L) 1*) achieves the 
same result, although both occurrences of b! 1 will be replaced. 


cross-mult &optional ( fnum.s *) [Strategy] 

When the various rewrite rules fail to produce the desired effect in eliminating divisions, 
cross-mult may be used to explicitly perform “cross multiplication” on one or more re- 
lational formulas. For example, a/b < c/d will be transformed to ad < cb. The strategy 
determines which lemmas to apply based on the relational operator and whether negative 
divisors are involved. Cross multiplication is applied recursively until all outermost division 
operators are gone. 

cross-mult also tries to do something reasonable in case the denominators are not 
known to be strictly positive or negative. Lemmas provided in theory extra_real_props, 
such as 
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div_mu.lt _pos_neg_ltl : LEMMA 

z/nOy < x IFF IF nOy > 0 THEN z < x * nOy ELSE x * nOy < z ENDIF 

are used to carry out cross multiplication using conditional expressions. If the denominators 
are of type posreal or negreal, however, these lemmas are not required. 


cross-add &optional ( fnums *) [Strategy] 

Performing “cross addition” is handled in most cases by move-terms. There are times, 
however, when it is desirable to find subtractions automatically and add the subtrahends to 
both sides. This type of cross addition is performed by cross-add, applying the procedure 
recursively until all outermost subtraction operators on either side of the relational formulas 
are gone. 


factor fnums &optional (side *) ( term-nums *) (id? nil) [Strategy] 

factor! expr-loc &optional (term-nums *) (id? nil) [Strategy] 

If the expression on side of each formula in fnums has multiple additive terms, factor 
may be used to extract common multiplicative factors and rearrange the expression. The 
additive terms indicated by term-nums are regarded as bags of factors to be intersected for 
common factors. Terms not found in term-nums are excluded from this process. If side 
is *, both sides will be factored separately using term-nums, which might not be useful 
unless term-nums is also *. The default case of “(factor <fnums>)” tries to factor both 
sides (separately) using all the terms of each side. Currently, there is no attempt to handle 
divisions; only multiplications within additive terms are recognized by the factoring process. 

In the ! variant, the expr-loc argument supplies a location reference to identify the target 
expression(s). Multiple expression locations may result from a single expr-loc argument. 
Each will be processed separately. 

If the optional argument id? is set to T, then the additive terms are wrapped in an 
application of the identify function id after factoring. This prevents later distribution of 
the multiplication operators by subsequent prover commands, which might undo the work 
of factor before the factored expressions can be used. 

As an example, suppose formula 4 has the form 

f(x) = 2*a*b + c*d-2*b 

and the command “(factor 4 R (1 3) T)” is issued. Then the strategy will rearrange 
formula 4 to: 

f(x) = 2 * b * id(a - 1) + c * d 

For a more complicated example, (factor! (! 4 R (->* "cos") 1)) factors the ar- 
gument of each instance of the cos function on the right side of formula 4. 


transf orm-both fnum transform, &optional (swap nil) (try-just nil) [Strategy] 

A generalized “both sides” command is offered by transf orm-both, although it is unable 
to select suitable lemmas and therefore leaves that work for the user. The idea is to apply 
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an arbitrary transform to both sides of a relational formula, where the transform is written 
as a parameterized PVS expression. This mechanism is described in full in Section 5.1; a 
special case is used here. The strategy itself may be viewed as a special case of the strategy 
invocations described in Section 5.2. 

The transform expression uses the string ‘7,1” to represent the left- and right-hand side 
expressions in the relation. Hence the transform can be regarded as a macro or template 
expression with “ 0 / 0 l” serving as an implicit macro or template parameter. As an example, 
suppose formula —3 is “a/b = c/d.” Invoking the command 

(transform-both -3 "2 * sqrt(%l)") 

takes the square root of both sides of formula —3 then multiplies by 2. A case split is 
introduced based on the formula 

2 * sqrt(a/b) = 2 * sqrt(c/d) 

Proof of the justification step can be tried or deferred until later. The flag swap is used to 
indicate when the sides should be swapped (e.g., when multiplying by a negative number). 

Usage: (transform-both 3 "-PI * %1" T (ground)) multiplies both sides by — 7r, 
swapping the two sides in the process, and tries to prove the transformation is valid using 

ground. 


3.3 Strategies for Manipulating Products 

To enhance reasoning capabilities for nonlinear arithmetic, we provide several strategies 
for manipulating products or generating new products. This supports an overall approach 
of first converting divisions into multiplications where necessary, then using a broad array 
of tools for reasoning about multiplication. Many of these manipulations apply lemmas 
already present in the prelude. Use of the strategies allows proof construction without 
detailed knowledge of these lemmas or the need to remember their names. 

permute-mult fnum,s feoptional (side R) ( term-nums 2) ( end L) [Strategy] 

permute-mult ! expr-loc &optional (term-nums 2) (end L) [Strategy] 

When there are three or more multiplicative terms in a product, it is sometimes difficult to 
make progress because the terms appear in an undesirable order or the association of terms 
gets in the way of applying lemmas. This can impede the application of various simplifi- 
cations such as cancellation. To remedy the situation, a user can apply permute-mult to 
reorder terms in a product. 

To perform this task, as well as several others in this group of strategies, the user needs 
to refer to individual terms in a product. This is done using the same method as earlier 
strategies. After identifying the expression to draw terms from, the argument term.-nums 
is used to supply a single term number or list of term numbers. Terms in a product are 
numbered left-to-right starting with number 1. Parentheses are ignored for the purpose of 
numbering terms. 
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For end = L, the action of permute-mult is as follows. Let the expression on side of a 
formula in fnums be a product of terms, P = t\* Identify a list of indices I ( term - 

nurns) drawn from {1, . . . ,n}. Construct the product t^ * ... * t tl where E I. Construct 
the product tj x * . . . * tj m where j ^ E {1, . . . ,??,} — I. Then rewrite the original product P 
to the new product * ... * t H * tj 1 * ... * tj m ■ Thus the new product is a permutation of 
the original set of factors with the selected terms brought to the left in the order requested. 
For end = R. the selected terms are placed on the right. 

In the ! variant, the expr-loc argument supplies a location reference to identify the target 
expression(s). Multiple expression locations may result from a single expr-loc argument. 
Each will be processed separately. 

Usage: (permute-mult 3 L (4 2)) rearranges the product on the left side of formula 
3 to be t4 * t2 * tl * t3, with the default association rules making it internally repre- 
sented as ((t4 * t2) * tl) * t3. 

name-mult name fnum side &optional ( term-nums *) [ Strategy } 

name-mult! name expr-loc & optional ( term-nums *) [Strategy] 

With name-mult a user can take the action of permute-mult one step further. After select- 
ing and extracting a product P of subterms to place on the left of the new product, P is 
assigned a name and a name-replace operation is carried out so that P = name is added 
as a new antecedent formula. In the ! variant, if multiple locations result from expr-loc , 
only the first one is processed. 

Usage: (name-mult "prodl" 3 L (4 2) ) rearranges the product on the left side of for- 
mula 3 to be PR0D1 * tl * t3 and adds the equality t4 * t2 = PR0D1 to the antecedents. 

recip-mult fnums side [ Strategy ] 

recip-mult ! expr-loc [ Strategy ] 

With recip-mult a user can convert an expression from a division to a multiplication 

by the reciprocal of the divisor. This presents an alternative way to deal with divisions 

from that offered by the cross-mult strategy. Reciprocals might be preferable when it is 
necessary to maintain a formula in the form of an equation such as x = y * (1/z) because 
substitution for x is anticipated shortly. Reciprocals also help when applying lemmas that 
assume expressions are in product form. In the ! variant, if multiple locations result from 
expr-loc, each is processed separately. 

Usage: (recip-mult 2 R) turns the (top-level) division on the right side of formula 2 
into reciprocal multiplication. 


isolate-mult fnum , feoptional ( side L) ( term-num 1) ( sign +) [Strategy] 

isolate-mult is used to migrate factors from a product to a division on the other side of 
a relation. Generally this is undesirable, but there are circumstances where solving for a 
term found within a product is necessary to enable later replacement actions. Given that 
formula fnum has the form Re ( side is L), selecting term i for isolation produces 

the new formula ti R e/(ti * . . . * ti-i * t t+ \ * . . . * t n ). For inequalities, the sign argument 
may be used to indicate when this divisor is a negative quantity. A case split is introduced 
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to establish that the divisor is positive or negative as claimed. 

Usage: (isolate-mult 4 L 3 +) divides both sides by all of the left-side terms of 
formula 4 except number 3, which collectively forms a positive product. 

mult-eq rel-fnum eq-fnum &optional ( sign +) [Strategy] 

Sometimes it is helpful to generate a new relation based on the products of terms from 
two existing formulas. Given a relational formula a R b and an antecedent equality x = y. 
mult-eq forms a new antecedent or consequent relating their products, a * x R b * y. If I? 
is an inequality, the sign argument can be set to one of the symbols in {+, 0+, 0-} to 

indicate the polarity of x and y (positive, negative, nonnegative, nonpositive). A sign of * 
is not supported (yet). 

Usage: (mult-eq -3 -2 -) multiplies the sides of formula —3 by the sides of equality 
—2, which are assumed to be negative, (mult-eq -2 -2 -) would square both sides of —2. 

mult-ineq fnuml fnum2 feoptional (signs (+ +)) [Strategy] 

In certain cases, the terms of two inequalities can be used to generate a new inequality. 
Given two relational formulas fnuml and fnum2 having the forms a R\ b and x R -2 y, 
mult-ineq forms a new antecedent relating their products, a * x R% b * y. If i ?2 is an 
inequality having the opposite direction as Ri, mult-ineq proceeds as if it had been y R! 2 x 
instead, where Rf is the reverse of T{> . The choice of R : > is inferred automatically based 
on /?!, R '2 , and the declared signs of the terms. R>, is chosen to be a strict inequality if 
either R\ or R 2 is. If either formula appears as a consequent, its relation is negated before 
carrying out the multiplication. 

Not all combinations of term polarities can produce useful results with mult-ineq. 
Therefore, the terms of each formula are required to have the same sign, designated by the 
symbols + and -. Inequalities on terms of different polarities are not supported, largely 
because the truth of whether an inequality holds on the products depends on the relative 
magnitudes of the products rather than just the polarity of their factors. The formulas are 
allowed to have different signs, however, relative to each other. For example, fnuml could 
be an inequality on positive terms while fnum2 is on negative terms. The signs argument 
must be a list of two signs denoting the polarities of fnuml terms and fnum2 terms. 

Usage: (mult-ineq -3 -2 (- +)) multiplies the sides of inequality formula —3 by the 
sides of inequality —2, which are assumed to relate negative and positive values, respectively, 
(mult-ineq -2 -2) would square both sides of —2. 


mult-cases fnum &optional (abs? nil) ( mult- op *1) [ Strategy ] 

Case analyses for relational formulas containing products are generated by mult-cases. 
Two types of relations are accommodated. If fnum has the form x * y R 0 (or 0 R x * y) , 
mult-cases will rewrite fnum, to two cases relating x and y to 0, as appropriate. Some 
flattening and simplification will be attempted after rewriting. 

If fnum, is a consequent inequality of the form a * b R c * d. mult-cases will generate 
sufficient conditions to establish the inequality by considering relations between a and c, 
and between b and d. Likewise, for an antecedent inequality of this form, mult-cases will 
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generate necessary conditions for fnum. The lemmas used by mult-cases contain instances 
of the abs function, which are normally expanded. To suppress this expansion, set abs? to 
T and the applications of abs will be retained. 

Some branching of the sequent is likely with this second relational form. Moreover, 
when the terms are unconstrained real values, the conditions generated are complex. Much 
better simplification occurs if the terms are known to be (non)positive or (non)negative. 
All combinations of term polarities should produce meaningful results. 

IF fnum is an inequality of the form a*b R c or a R c*d, fnum is first transformed into 
the form a*b R c*d by multiplying c or a by 1. m,ult-op may be set to *1 (1*) to multiply 
on the right (left). Case analysis then proceeds as in the general case described above. 

Usage: (mult-cases 2) generates conditions for the products found in formula 2. 


mult-extract name fnum &optional ( side *) ( term-nums *) [ Strategy } 

mult-extract! name expr-loc &optional ( term-nums *) [ Strategy } 

Operating at a somewhat higher level, mult-extract performs a series of steps to simplify 
sums of products and put them into a form amenable to further manipulation. First, it 
extracts the additive terms specified by term-nums from the expression found on side of 
formula fnum. Each additive term is treated as a product of factors, some of which may 
contain divisions. Each product term thus selected is extracted using name-replace to 
form a new antecedent equality. A name for each product is constructed by appending an 
index to the argument name. After each equality is established, the divisors are multiplied 
out to remove top-level division operations (similar to the action of cross-mult). Then 
common factors on both sides of each equality are identified and canceled. In the ! variant, 
if multiple locations result from expr-loc , only the first one is processed. 

Usage: (mult-extract 2 L (1 3)) applies the prescribed sequence of manipulations 
to additive terms 1 and 3 on the left side of formula 2. 


21 



Chapter 4 


Extended 


Expression Notation 


To enhance the effectiveness of prover strategies, we provide a means for specifying extended 
expressions as strategy arguments. Two major types of extensions are included: location 
references and textual pattern matching. Location references allow a user to indicate a 
precise subexpression within a formula by giving a path of indices to follow when descending 
through the formula’s expression tree. Pattern matching allows strings to be found and 
extracted using a specialized pattern language that is based on, but much less elaborate 
than, regular expressions. Together the extensions offer much more flexibility for entering 
PVS expressions than simple text strings. 

4.1 General Syntax 

Extended expressions are specified using a combination of string literals and Lisp-oriented 
notation. Evaluation of extended expressions takes place during strategy execution, yielding 
sets of values that are used to form arguments to built-in prover commands. The results 
of this evaluation usually denote expressions in the PVS language but need not do so. 
Expression strings can be arbitrary text that wull be combined later with other text to form 
more meaningful strings. The substitution mechanism presented in Section 5.1 enables this 
type of recombination. 

An extended expression is recursively defined to have one of the following forms: 

• A literal text string (characters in double quotes). 

• An integer denoting a formula number. The string value of such an expression is the 
textual representation of the PVS formula. 

• A symbol denoting either a formula label or one of the special symbols +, — , *, with 
their usual meanings as sets of formulas. 

• A location reference having the form (! <ext-expr> il ... in), where 
are index values. 

• A pattern match having the form (? <ext-expr> pi ... pn), where pi, . . . , p n are 
pattern strings. 
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• A list (el ... en), where ei,...,e n are extended expression specifications. After 
evaluation, the lists generated by ei, . . . ,e n will be concatenated into a single list. 

Note that numbers when used as extended expressions do not denote numbers in the PVS 
language as they usually do at the prover interface. Numbers denote formulas; string 
literals such as "4" must be used to indicate PVS numbers. Similarly, formula labels must 
be entered as symbols rather than strings, e.g., sq_fmla rather than "sq_fmla". Also note 
that the location reference and pattern match forms take another extended expression as 
their first “argument.” In practice, this is almost always a number or symbol. Nesting of 
extended expressions is possible, although some combinations do not yield useful results. 

Evaluation of an extended expression can result in zero or more separate strings or 
objects being generated. Internally, evaluation produces a list of descriptors, each of which 
contains a text string, the number of the formula of origination, and the Common Lisp 
CLOS object that represents a PVS expression. Only the string component exists in all 
cases. For example, pattern matches generally do not produce a CLOS object because 
matches return arbitrary strings that need not correspond to PVS expressions. 

For the strategies of Section 5.2, multiple expression specifications may be supplied as 
arguments. What happens in such cases is that each specification gives rise to an arbitrary 
number of descriptors. All the descriptor lists are then concatenated to build a single 
descriptor list before substitutions are performed. 

4.2 Location References 

A location reference has the form (! <ext-expr> il ... in), where <ext-expr> is the 
base expression or starting point, which must describe the location of a valid PVS expression. 
The index values {ij} are used to descend the parse tree to arrive at a subexpression, 
which becomes the final value of the overall reference. Actually, the final value is a list of 
expressions, which allows for wild-card indices to traverse multiple paths through the tree. 
Moreover, the index values may include various other forms and indicators used to control 
path generation. 

Location references are so named because they specify sites within the current sequent. 
This property allows them to be used as arguments for certain strategies where a mere text 
string is inadequate. For example, the factor! strategy can factor an expression in place 
using this feature even if the target terms appear in the argument to a function. Thus, 
location references can be regarded as somewhat analogous to array or structure references 
in a procedural programming language. 

An example of a simple location reference is ( ! -3 2), which evaluates to the right- 
hand side (argument 2) of formula -3. If this formula is “x! 1 = cos (a! 1),” then the string 
form of the location reference is “cos (a! 1).” Adding index values reaches deeper into the 
formula, e.g., (! -3 2 1) evaluates to “all.” Breadth can be achieved as well as depth; 
( ! -3 *) evaluates to a list having one element for each side of the formula. 

Strictly speaking, formula numbers and symbols are also location references, albeit in 
shorthand form. In fact, the extended expression 4 is equivalent to ( ! 4). This establishes 
the base case for the definition. Indices determine which paths will emanate from this base 
expression. 
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Index values and directives {ij} may assume one of the following forms: 

• An integer i in the range 1, . . . , k, where k is the arity of the operator or function at 
the current point in the expression tree. Paths follow the i' h branch or argument. If i 
is the last index (i„), the value returned for the location reference is the i th argument 
of the current subexpression. Negative integers allow indexing from right to left, that 
is, -1 selects argument k, -2 selects k — 1 , etc. 

• One of the symbols L or E, which denote the index values 1 and 2, leading paths 
through the first or second branch accordingly. 

• The index value 0, which returns the function symbol of the current expression, pro- 
vided it is a function application. In a higher-order function application, the function 
itself can be an expression, as in f(x)(y). Indices after the 0 can be supplied to retrieve 
components of the function expression. 

• The wild-card symbol *, which indicates that this path should be replicated n times, 
one for each argument expression. The values returned are those generated by all n 
of the paths. 

• A list (jl ... jm) of integers indicating which argument paths should be included 
for replication, i.e., a subset of the * ease. 

• A complement form ( ' jl ... jm) that indicates all argument paths should be fol- 
lowed except those in {ji - } . 

• One of the deep wild-card symbols **}, which indicates that this path should 

be replicated as many times as needed to visit all nodes in the current subtree. The 
values returned are the leaf objects (terminal nodes) for the nonterminal nodes 
for and all nodes (subexpressions) for **. 

• A text string serving as a guard to enable continuation of the current path(s). If 
the function or operator symbol of the current subexpression is equal to the string, 
path elaboration continues. Otherwise, the path is terminated and an empty list is 
returned. Guards act to select desired paths from multiple candidates. 

• A list (si ... sk) of strings that serves as a guard in the form of patterns to be 
matched in the manner of Section 4.3. 

• A form (-> gl ... gk) that serves as a go-to operator to specify a systematic search 
down and across the subtree until the first path is found having intermediate points 
satisfying all the guards {#;} in sequence. The selected path generates the final value. 
Each guard <77 may be either a string or list of strings, with meanings as described 
above. 

• A form (->* gl ... gk) that behaves the same as (-> . . . ) except that all eligible 

paths are found and returned as values. 
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Formula -1 


Formula -2 


Formula 1 


\ /\ 


r ! 1 


/\ /\ 

x ! 1 r ! 1 y ! 1 r!l 


/\ 

* 1 

/\ 


Figure 4.1: Expression trees for formulas in Table 4.1. 


sqrt 

sqrt 

r! 1 

sq 


/ 


/\ 


x! 1 4 

Table 4.1. 



We note a few fine points about these features. Infix and prefix function applications are 
considered equivalent for indexing purposes; in both “x ! 1 * y ! 1” and “atan(x ! 1 , y ! 1) 
x ! 1 is argument 1 and y ! 1 is argument 2. Out of range index values cause termination 
of a path and an empty return value. The same is true of index lists that “fall off the 
end” of a path by supplying too many indices. The deep wild-cards {-*,*-,**} may be 
followed by other indicators, which use the various subexpressions as their starting points. 
During a tree search, backtracking is performed as needed so that the go-to operators -> and 
->* find any (upper level) paths that meet the indexing specification. If there are nested 
applications of a function, for example, only the upper-most subexpression will be returned. 
Also note that repeated function names in a go-to form, such as ( ! 2 (->* "sq" "sq")), 
will not descend to the lower expression(s). The second occurrence of the guard "sq" will 
be immediately matched by the expression reached by the first occurrence. To reach the 
lower " sq" requires a specification such as ( ! 2 (->* "sq") 1 (->* "sq")). 

A few special indexing cases exist for arithmetic expressions. They result in some 
apparent “flattening” of the parse tree during traversal. The conventions make indexing 
more convenient for arithmetic terms and correspond more closely to our usual algebraic 
intuition for numbering terms. The conventions are as follows. 

• Additive terms, i.e., terms that are arguments of a + or — operator, are counted left to 
right irrespective of the associative groupings that may be in effect. They are treated 
as if they were all arguments of a single addition/subtraction operator of arbitrary 
arity. 

• Multiplicative terms, i.e., terms that are arguments of a * operator, are counted left to 
right irrespective of the associative groupings that may be in effect. They are treated 
as if they were all arguments of a single multiplication operator of arbitrary arity. 

Parentheses for these associative operators are effectively ignored during the flattening 
process, e.g., for the three expressions “x * (y * z)”, “x * y * z”, and “(x * y) * z”, 
term 2 is y in each case. 

We illustrate the formulation of location references using the notation just described. 
Table 4.1 gives the result of evaluating location references with respect to the formulas 
shown beneath the table. Figure 4.1 depicts the expression trees for these formulas. 
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Table 4.1: Examples of location reference expressions. 


Location reference 

Expression strings 

( ! 

-2) 

r!l=2*x!l+l 

( ! 

-2 L) 

r ! 1 

(! 

-2 R) 

2 * x ! 1 + 1 

(! 

-2 R 1) 

2 * x ! 1 

( ! 

-2 R 2) 

1 

(! 

-2 R 1 2) 

x ! 1 

(! 

-1 L 2 1) 

y!i 

(! 

1 R 1) 

sq(x ! 1 / 4) 

(! 

1 R 1 1) 

x ! 1 / 4 

(! 

1 R 1 1 2) 

4 

(! 

-2 *) 

r! 1, 2 * x ! 1 + 1 

(! 

-1 L 2 *) 

y! 1, r!l 

0 

-1 L * 1) 

x!l,y!l 

(! 

-1 L * *) 

x ! 1, r ! 1, y ! 1, r!l 

(! 

-1 L (* 1)) 

y ! 1 * r ! 1 

(! 

-2 R -*) 

2. x ! 1, 1 

0 

1 R -*) 

x ! 1, 4 

(! 

-2 R **) 

2 * x! 1 + 1,2 * x! 1, 2. x! 1, 1 

(! 

1 R 1 **) 

sq(x!l / 4),x!l / 4,x!l,4 

0 

— II — II ^ 

r!l=2*x!l+l 

(! 

-2 * "+") 

2 * x ! 1 + 1 

(! 

1 (-> "sqrt")) 

sqrt (r ! 1) 

(! 

1 (->* "sqrt")) 

sqrt (r ! 1), sqrt (sq(x! 1 / 4)) 

( ! 

1 (-> "sq")) 

sq(x ! 1 / 4) 

(! 

1 (-> "sq") 1) 

x ! 1 / 4 

(! 

-1 (-> "+") *) 

x ! 1 * r ! 1, y! 1 * r!l 

(! 

-1 (->* "+" "*") *) 

x ! 1, r ! 1, y ! 1. r!l 

( ! 

1 *- 0) 

<, sqrt, sqrt. sq. / 


where the formulas are as follows: 


{-1} x ! 1 * r ! 1 + y ! 1 * r!l > r!l - 1 
[-2] r!l=2*x!l+l 


[1] sqrt(r!l) < sqrt(sq(x!l / 4)) 
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Combinations of indexing directives offer useful ways to find multiple expressions. For 
instance, (! * R "+") finds all right-hand sides having the form of an addition. Similarly, 
( ! + (->* "cos") 1) finds all arguments of the cos function in the consequent formulas. 
Another example is ( ! - "=" L), which finds the left-hand sides of antecedent equalities. 

4.3 Pattern Matching 

Recall that a pattern match is specified using the form (? <ext-expr> pi ... pn). Each 
pattern pj is expressed as a text string using a specialized pattern language. Unlike location 
references, pattern matches usually produce only a text string and lack a corresponding 
CLOS object for a PVS expression. The patterns pi,...,p n are applied in order to the 
textual representation of each member of the base expression list. In each case, matching 
stops after the first successful match among the {pj } is obtained. All resulting output 
strings are collected and concatenated into a single list of output strings. 

4.3.1 Pattern Language 

The pattern language was designed to meet the anticipated needs of prover users in describ- 
ing PVS expressions. Pattern matching features are implemented in terms of the built-in 
regular expression package bundled with PVS’s Allegro Common Lisp environment. This 
module provides only basic regular expression features, much less sophisticated than Peri- 
style regular expressions. Nevertheless, it appears to be adequate for the purpose at hand, 
and runs faster than more elaborate matching engines. 

A pattern string may denote either a simple or a rich pattern. Simple patterns are easier 
to express and are expected to suffice for many everyday matching applications. When more 
precision is required, rich patterns may be used for more expressive power. 

No alternation is provided in the pattern language itself. To achieve the effect of alter- 
nation, multiple pattern strings may be supplied instead of a single pattern. Each pattern 
in the list is tried in sequence until a match is obtained. Thus the output strings issue from 
the first pattern to produce a nonempty result. 

An empty list of patterns will match no strings. A null pattern (""), however, matches 
any string but returns no useful values. Typically, various substrings are extracted and 
returned as the result of the matching process. Successful matches that return no output 
strings result in the default value of a single empty string. 

4.3.2 Simple Patterns 

Simple patterns allow matching against literal characters, whitespace fields, and arbitrary 
substrings. Pattern strings comprise a mixture of literal characters and meta-strings for 
designating text fields. Each literal character must match itself in the target string. Each 
field designator matches a string of zero or more characters in the target string. 

Meta-strings denote either whitespace fields or non-whitespace fields. A whitespace field 
is indicated by a space character in the pattern, which stands for a field of zero or more 
whitespace characters (space, tab, form feed, or newline). A non- whitespace field is a meta- 
string consisting of the percent ('/,) character followed by a digit character (0-9). Such a 
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Table 4.2: Examples of simple pattern matching using the formulas in Table 4.1 


Pattern 

Matching string(s) 

Captured fields 

(? 1 "71 (r ! 1) ") 

sqrt (r ! 1) 

sqrt 

(? 1 "sqrt (sq(7l) ) " ) 

sqrt (sq(x ! 1 / 4) ) 

x ! 1 / 4 

(? -2 "r ! 1 = 71") 

r ! 1 = 2 * x ! 1 + 1 

2 * x! 1 + 1 

(? 1 "71(70) <") 

sqrt(r!l) < 

sqrt 

(? -1 "> 71 - 70") 

> r!l - 1 

r! 1 

(? 1 "71(70) < 71(72)") 

All of formula 1 

sqrt, sq(x!l / 4) 

(? ( ! (-2 1) E) "7lx!l") 

2 * x ! 1, sqrt (sq(x ! 1 

2 * , sqrt(sq( 


field matches zero or more arbitrary characters in the target string. Both capturing and 
non-capturing fields are provided. A capturing field causes the matching substring to be 
returned as an output string. 

The meta-string 70 denotes a noncapturing field, while those with nonzero digits are 
capturing fields. If a nonzero digit d is the first occurrence of d in the pattern, a new 
capturing field is thereby indicated. Otherwise, it is a reference to a previously captured field 
whose contents must be matched. Note that the nonzero digits used must be consecutive 
starting with 1 (e.g., "°/„l = 73" is improper). 

We illustrate the formulation of simple patterns using the notation just described. Ta- 
ble 4.2 shows the result of matching various patterns against the sample formulas. 

4.3.3 Rich Patterns 

Rich patterns follow the same basic approach as simple patterns, but add extensions for 
multiple matching types and multiple text field types. To be distinguished from simple 
patterns, rich patterns must begin with the character To specify the type of matching 
requested, the second character of the pattern encodes the user’s choice. Thus a rich pattern 
has the form 0<match typexpattern string>. 

Table 4.3 shows the match types currently offered. Note that the default (partial string 
match) can be obtained by omitting the match type code, in which case the second character 
is interpreted as part of the pattern string. Obviously, this will not work if the first character 
of the pattern string is one of the match type encodings. 

In a full string match, the pattern must match against the entire text string under 
consideration. A partial string match is less strict, admitting any substring that satisfies 
the pattern. Generally, the left-most substring with the largest extent is chosen for a partial 
match. 

The type-s match allows a partial match to determine a boolean outcome, then returns 
the full input string as the result if successful. In effect, this lets matching be used as a 
filter to allow all or none of the string to pass. None of the strings captured via 7,1, 72, 
etc., will be included in the result. Also returned is the CLOS object for the input string, 
where applicable. This allows the result of a type-s match to be used as input to a location 
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Table 4.3: Character encoding for match types. 


Character Match type 


f 

P 

s 

t 

b 

<digit> 

Other 


Full string match 

Partial string match (first substring to match) 

Partial match returning full string if successful 
Top-down expression matching 
Bottom-up expression matching 

Top-down expression matching, skipping top-most <digit> levels 
Partial string match 


reference. 

Expression-oriented matching is also provided, which allows matching to proceed with 
respect to the parse tree of an expression. In top-down matching, a pre-order traversal 
of the tree is performed where matching is attempted at each visited node. If the textual 
representation of the expression denoted by the node matches the pattern, traversal stops 
and returns the match result. Otherwise, matching is attempted on each subexpression in 
left-to-right order. Currently, the most common syntactic features of PVS expressions are 
accommodated, e.g., infix and prefix function applications, but not all language features are 
included. If a pattern does not match as expected, it might be due to this incompleteness 
in the current implementation. We will extend the matching later to incorporate other 
elements of the PVS grammar. 

Bottom-up expression matching (post-order traversal) may be requested as well as top- 
down matching. In addition, restricted top-down matching may be performed by skipping 
the top few levels of the expression tree. This is useful to avoid undesired matches caused 
by greedy matching of parenthesized expressions. Naturally, complex formulas can give rise 
to expensive searches when these expression-oriented forms of matching are used. 

Capturing and non-capturing text fields are extended in rich patterns to allow multiple 
field types. The basic field designator is extended to a three-character sequence of the form 
%<digit><f ield type>. Table 4.4 shows the field types currently offered. If the field type 
character is omitted, the default type is *, which is the same as the field type for simple 
patterns. Field types in rich patterns enable more discriminating searches than those of 
simple patterns. 

To illustrate the use of these extended pattern features, Table 4.5 shows the result of 
matching various rich patterns against the sample formulas. 


29 



Table 4.4: Character encoding for text field types. 


Character 

Field type 

* 

Zero or more arbitrary characters 

+ 

One or more arbitrary characters 

& 

One or more arbitrary characters, where the first 
and last are non-whitespace characters 

i 

PVS identifier (allows ! for prover variables) 

# 

Numeric field (digits only) 

Other 

Same as * 


Table 4.5: Examples of rich pattern matching using the formulas in Table 4.1 


F# Pattern 


Matching string 


Captured fields 


r!l=2*x!l+l 


2 * x! 1 + 1 


-2 @pr ! 1 = 7.1& 

-2 @p7,l# * 7,2i 
-2 @s7,l# * 7,2i 
-2 @f7,l# * 7.2i 
-2 @p7,l# * 7,1 

1 0p7„li(r!l) 

1 @p7,li(7»0*) 

1 @s7»li(7»0*) 

1 @psqrt (sq(7,l*) ) 

-1 @p7»li - 7.0* 

1 @tsq(7.1*) 

1 @lsq(7.1*) 

1 @2sq(7.1*) 

1 @bsq(7»l*) 

-1 017.1& * 7.2& 

-1 027.1& * 7.2 & 

-1 0b7.1& * 7.2 & 

1 Of7.1i(7.0*) < 7,1 (7,2*) 

-2 @p7,l&=7,2& 


2 * x! 1 
2 * x ! 1 
None 
None 

sqrt (r ! 1) 

sqrt (r ! 1) 

sqrt (r ! 1) 

sqrt(sq(x!l / 4)) 

r ! 1 - 1 

sq(x ! 1 / 4)) 

sq(x ! 1 / 4)) 

sq(x!l / 4) 

sq(x!l / 4) 

x ! 1 * r ! 1 + y ! 1 * r!l 

x ! 1 * r ! 1 

x ! 1 * r ! 1 

All of formula 1 

None 


2, x ! 1 

All of formula -2 


sqrt 

sqrt 

All of formula 1 
x ! 1 / 4 
r! 1 

x ! 1 / 4) 
x ! 1 / 4) 
x ! 1 / 4 
x ! 1 / 4 

x ! 1 * r ! 1 + y! 1, r!l 
x ! 1 , r ! 1 
x ! 1 , r ! 1 

sqrt , sq(x ! 1 / 4) 
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Chapter 5 

General Purpose Strategies 


This chapter describes a set of general purpose PVS prover strategies for manipulating 
arbitrary sequents. They are not specialized for arithmetic. Some offer generic capabilities 
useful in implementing other strategies for specific purposes. Table 5.1 lists the strategies 
provided along with their formal argument lists. 

Often prover users would like ways to capture expressions from the current sequent and 
use them to build arguments to prover commands such as case. We have provided extended 
expressions to achieve this capture. Next we add a parameter substitution technique to yield 
a major new way to formulate prover commands. To complete the suite, we add a family 
of higher-order strategies that substitute strings and formula numbers into a parameterized 
command (rule or strategy). The command can be regarded as a template expression 
(actually, a Lisp form ) in which embedded text strings and special symbols can serve as 
formal parameters for substitution. 

Consider a simple example. Suppose formula 2 is 

sin(2 * PI * omega! 1 + delta! 1) >= 0 
and we wish to claim that the sin argument is nonnegative. The command 
(invoke (case "%1 >= 0") (! 2 L 1)) 
accomplishes this task by invoking the prover command 
(case "2 * PI * omega! 1 + delta! 1 >= 0") 
as if it had been typed in this form. 

5.1 Parameter Substitution 

The outcome of evaluating an extended expression can be used to carry out textual and 
symbolic substitutions within a parameterized command. Such a command is assumed to 
be a Lisp form: 

(<rule/strategy> <argument 1> ... <argument n>) 
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Table 5.1: Summary of general purpose strategies. 


Syntax 

Function 

(invoke command &rest expr-specs) 

(for-each command forest expr-specs) 

(f or-each-rev command &rest expr-specs) 
(show-subst command &rest expr-specs) 

(claim cond foopt (try-just nil) 

&rest expr-specs) 

(name-extract name forest expr-specs) 

Invoke command by instantiating 
from expressions and patterns 
Instantiate and invoke separately 
for each expression 
Invoke in reverse order 
Show but don’t invoke the 
instantiated command 
Claims condition on terms 

Extract & name expr, then replace 

(move-to-front &rest fnums) 
(rotate — ) 

(rotate++) 

Reorder sequent formulas 
Rotate antecedent list 
Rotate consequent list 

(use-with lemma &rest fnums) 

(apply-lemma lemma &rest expr-specs) 
(apply-rewrite lemma &rest expr-specs) 

Use a lemma with formula 

preferences for instantiation 
Use lemma with expressions 
Rewrite with expressions 


The argument expressions can be numeric, textual, or symbolic values as well as paren- 
thesized expressions. This can lead to nesting of arbitrary depth. As usual at the prover 
interface, neither the top-level parenthesized expression nor its arguments are evaluated as 
normal Lisp expressions. The interpretation of arguments is left for the proof rule to carry 
out when it is finally invoked. 

Input data for the substitution process is a list of expression descriptors computed during 
the evaluation of one or more extended expression specifications. As described in Chapter 4, 
each descriptor contains a text string and, optionally, a formula number and CLOS object. 
The descriptor list is the source of substitution data while the parameterized command is 
its target. 

Within this framework, we allow two classes of substitutable data: literal text strings 
and Lisp symbols. The top-level parenthesized expression is traversed down to its leaves. 
Wherever a string or symbol is encountered, a substitution is performed. The final com- 
mand thus produced will be invoked as a prover command in the manner defined for the 
chosen higher-order strategy. (In Lisp programming terms, this process can be imagined 
as evaluating a backquote expression with specialized implicit unquoting. It also has some 
similarities to substitution in Unix shell languages as well as the scripting language Tel.) 

Parametric variables for substitution are allowed as follows. Within literal text strings, 
the substrings 7,1, . . . , 79 serve as implicit text variables. The substring 71 will be replaced 
by the string component of the first expression descriptor. The other 7-variables will be 
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Table 5.2: Special symbols for command substitution. 


Symbol 

Value 

$1, $2, ... 

nth expression descriptor 

$* 

List of all expression descriptors 

$ls , $2s , ... 

nth expression string 

$*s 

List of all expression strings 

$ln, $2n, ... 

Formula number for nth expression 

$*n 

List of all formula numbers 

$lj, $2j , ... 

CLOS object for nth expression 

$*j 

List of all CLOS objects 

$+ , $+s, $+n, $+j 

Duplicate-free versions of $* , $*s , $*n, $*j 


replaced in order by the corresponding strings of the remaining descriptors. 

Aggregations may be obtained using the string ’/„* and it variants. ’/»* will be replaced 
by a concatenation of all expression strings. ’/. , behaves the same except that it separates 
the strings using the delimiter “ , u ” . 

Certain reserved symbols beginning with the $ character are provided to serve as sub- 
stitutable symbolic parameters. Such symbols are not embedded within string constants 
as are the ’/.-variables; they appear as stand-alone symbols within the list structure of the 
parameterized command. The symbols $1, $2, etc., represent the first, second, etc., ex- 
pression descriptors from the list of available descriptors. These symbols should be used as 
arguments to strategies that require a location-reference type of extended expression. They 
may be used as arguments for strategies in this package whenever terms or formula numbers 
are called for. 

Variants of these symbols exist to retrieve the text string, formula number, and CLOS 
object components of a descriptor. These are needed to supply arguments for built-in prover 
commands, which are not cognizant of extended expressions. The symbols $ls, $ln and 
$lj serve this purpose. Note that CLOS object values have no use when entering prover 
commands from the keyboard. They are provided for the convenience of strategy writers. 

Aggregations may be obtained using the symbol $* and it variants. A list of all source 
expression descriptors is given by $* while the list of strings and formula numbers is given 
by $*s and $*n. Because one formula might be associated with multiple expressions, the 
descriptor list can contain duplicate formula numbers. A list without duplicates is available 
from the symbol $+n. Table 5.2 summarizes the special symbols usable in substitutions. 

We note that when using the list-valued symbols, their values are “spliced” into the 
surrounding Lisp expression. If they are used in a context that requires parentheses, they 
need to be supplied by the user. For example, if $+n has the value (1 3 5) , then (hide $+n) 
will be expanded to (hide 13 5). Conversely, (hide-all-but ($+n)) will be expanded 
to (hide-all-but (1 3 5) ). In the following sections we present more examples of how the 
’/.-variable and $- variable substitutions are applied to produce a final instantiated command. 
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5.2 Invocation Strategies 

The following higher-order strategies make use of the parameter instantiation features to 
construct and invoke prover command instances. 


invoke comm, and &rest expr-specs [ Strategy } 

This strategy is used to invoke command (a rule or strategy) after applying substitutions 
extracted by evaluating the expression specifications expr-specs. All expression descriptor 
lists are appended to form a single list before substitution occurs. Note that there is 
not a one-to-one correspondence between descriptors and expression specifications. Each 
specification can produce zero or more descriptors. 

As an example, suppose formula 3 is 

f (x ! 1 + y ! 1) <= f (a! 1 * (z ! 1 + 1)) 

Then the command 

(invoke (case "7.1 <= 7.2") (? 3 "f (7.1) <= f(7,2)")) 

would apply pattern matching to formula 3 and create the bindings 7.1 = "x ! 1 + y ! 1 " and 
7o2 = "a! 1 * (z ! 1 + 1) ", which would result in the prover command 

(case "x!l + y ! 1 <= all * (z!l + 1)") 

being invoked. An alternative way to achieve the same effect using location referencing is 
the following: 

(invoke (case "7.1 <= 7.2") (! 3 * 1)) 

String substitutions are not limited to command arguments that accept PVS language 
expressions. They may also be used to construct function, lemma and theory names. 

As another example, suppose we wish to hide most of the formulas in the current sequent, 
retaining only those that mention the sqrt function. We could search for all formulas 
containing a reference to sqrt using a simple pattern, then collect all the formula numbers 
and use them to invoke the hide-all-but rule. Applying invoke as follows 

(invoke (hide-all-but ($+n)) (? * "sqrt")) 

would hide all formulas except those containing the string sqrt. 


for-each command &rest expr-specs [ Strategy ] 

This strategy is used to invoke command repeatedly, once for each expression generated by 
expr-specs. The effect is equivalent to applying (invoke command <expr i>) n times. 

As an example, suppose we wish to expand every function in the consequent formulas 
that has the expression “n!l + 1” as its argument. The following command carries this 
out, assuming there is only one such expression per formula. 

(for-each (expand "7.1") (? + "@p7.1i(n!l + 1)")) 
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for-each-rev command ferest expr-specs [Strategy] 

This strategy is identical to f or-each except that the expressions are taken in reverse order. 

As an example, suppose we wish to find all the antecedent equalities and use them for 
replacement, hiding each one as we go. This needs to be done in reverse order because 
formula numbers will change after each replacement. 

(for-each-rev (replace $ln :hide? t) ( ! - "=")) 


show-subst command &rest expr-specs [Strategy] 

This strategy does not invoke any commands, but applies the matching and substitutions 
as the strategy invoke would. The instantiated command is displayed so the user can see 
the result of substitutions without actually attempting any proof commands. The idiom 

(show-subst ($*) <ext expr 1> ... <ext expr n>) 

allows a convenient display of the descriptors produced by evaluating extended expressions. 
Tweaking the expressions and iterating enables the user to converge on a correct formulation 
before invoking an actual prover command. 


claim cond ftoptional ( try-just nil) ferest expr-specs [Strategy] 

The claim strategy is basically the same as the primitive rule case, except that the formula 
expression is derived using the parameterization technique described in Section 5.1. It also 
differs by being limited to only two-way case splitting. The condition presented in argument 
cond is a parameterized string expression of the kind described in Section 5.1. It may be 
instantiated by the terms found in the &rest argument expr-specs. For example, to claim 
that a numerical expression lies between two others, we could use something like 

(claim "7,1 <= %2 & 7,2 <= 7,3" nil "a/b" "x+y" "c/d") 

to generate a case split on the formula: 

a/b <= x+y & x+y <= c/d 

Argument try- just allows the user to try proving the justification step (the second case 
resulting from the case split). 

Usage: (claim "7,1 + PI = 7,2" T "phi!l" "thetall") introduces a claim and tries 
to prove it using grind. 


name-extract nam.e &rest expr-specs [Strategy] 

Rather than invoking a command, this strategy is used to compute a list of expressions, 
then extract each expression string from it, assign a name to the expression, and finally, 
replace the expression by the name. If expr-specs evaluates to multiple expressions, unique 
names are formed by appending an index to name. The equality formulas generated by 
the internal name-replace commands are not hidden. This strategy is useful for removing 
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embedded expressions and lifting them to one side of an equality formula, where the various 
arithmetic manipulation strategies can be applied thereafter. 

Usage: (name-extract angle (? 3 "2 * sin(7,l)")) applies the pattern to find the 
argument to the sin function, giving it the name ANGLE, then replaces it throughout the 
sequent. 

5.3 Substitution Shortcuts 

To streamline user input for simple cases, we provide the following shortcuts usable during 
the substitution process. 

• Embedding extended expressions in strings. Commands such as 

(claim "%1 < 7,2" nil (! 12) (! 3 4)) 
may be rewritten to a form that embeds the extended expressions in the target string: 

(claim "7,! 1 27. <7,! 3 47.") 

Location references may be embedded by replacing the outer-most parentheses with 
percent characters. After evaluation, the first expression string generated by each 
location reference will replace the corresponding 7, ! . . . 7, substring. Concurrent use 
of 7»- variables in the same string is possible. Embedding pattern match expressions is 
also possible but not recommended because of the need to escape quote characters. 

• Embedding extended expressions in list structures. Commands such as 

(invoke (hide $*n) (? + "cos")) 

may be rewritten to a form that embeds the extended expressions in the target list: 
(invoke (hide (? + "cos"))) 

Either location references or pattern match expressions may be embedded this way. 
The effect is to extract the formula numbers yielded by the evaluation and substitute 
them for the ( ! . . . ) or (? . . . ) sublist. If the results need to be contained in a 
single list argument to a rule, add an extra set of parentheses, as in: 

(invoke (hide-all-but ((? + "cos")))) 

5.4 Formula Reordering Strategies 

The next group of strategies includes several for manipulating the order of formulas within 
a sequent. Formula reordering can be helpful before instantiating quantifiers using inst? 
or applying lemmas via the use rule. It also can be helpful as a component of higher level 
strategies where uniform placement of formulas is needed. 
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move-to-front ferest fnums [Strategy] 

Invoking move-to-front on a list of formulas causes them to be pulled to the front of their 
respective lists (antecedents or consequents). They remain in the same relative order that 
they appeared initially regardless of the order in which they are listed in argument fnums. 
Example: (move-to-front -4 3 -2 2) causes the new order to become -2, -4, -1, -3 b 2, 
3, 1. 

rotate — [Strategy] 

rotate++ [Strategy] 

These strategies cause the antecedent ( — ) or consequent (++) formulas to be “rotated,” 
i.e., the first formula is moved to the end and all the others move up by one. 

5.5 Lemma Invocation Strategies 

This final group of strategies is used to invoke lemmas in various ways not already provided 
by the built-in prover commands. 

use-with lemma &rest fnums [Strategy] 

The use command for importing and instantiating lemmas sometimes chooses wrong or 

useless variable instantiations. We could improve the chances for correct selection in some 
cases by reordering the formulas so that preferred terms are tiled earlier in the instantiation 
process. The use-with strategy implements this heuristic by creating a temporary copy 
of the terms in fnums and placing it at the front of the sequent (formula -1). Then a use 
command for lemma is invoked so that the search for instantiable terms begins with the 
temporary formula. The effect is to consider terms from the user’s preferred formulas (in 
the order given) before looking elsewhere in the sequent. Instantiation heuristics apply 
various criteria for suitability so this tactic might not achieve the desired effect. 

Usage: (use-with "sin_gt_0" 3 -2) tries to instantiate the variables of sin_gt_0 by 
first examining the terms of formulas 3 and -2. 


apply-lemma lemma &rest expr-specs [Strategy] 

apply-rewrite lemma &rest expr-specs [Strategy] 

Occasionally is it necessary to provide explicit instantiations when applying lemmas or 
rewrite rules. This happens when the prover’s automatic instantiation heuristics fail to 
pick out the desired expressions. In such cases, these two strategies provide an abbreviated 
way to force the binding of expressions to lemma variables. It is necessary to know the 
lemma variable names so that the expressions can be supplied in the correct order. PVS 
lists lemma variables in alphabetical order when the inst command is invoked. This is the 
order in which expressions should be supplied in the strategy command, apply-lemma has 
an effect similar to the use command, apply-rewrite is similar to rewrite, although only 
equality rules are currently handled. 
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Chapter 6 


Emacs Extensions 


This set of extensions introduces PVS prover shortcuts that help when manipulating se- 
quents. The package streamlines interactive strategy invocation by assisting with certain 
types of argument entry. It adds features similar to those of the PVS prover helps package 
originally developed by C. Michael Holloway of NASA Langley and now distributed with 
PVS. Also provided are miscellaneous Emacs features to help with proof maintenance and 
other assorted tasks. 

6.1 Prover Command Invocation 

Two specific interface features are incorporated. One is a means of invoking strategies that 
prompts the user through the argument list so it is unnecessary to memorize the formal 
argument lists of strategies. This works for all the built-in prover rules and strategies as 
well. The other feature allows the user to streamline cut-and-paste operations by supporting 
argument entry via mouse-dragging selections. This is helpful when it is necessary to include 
PVS expressions clipped from the current sequent. Both of these features are incorporated 
into a single TAB-command invocation sequence. 

The basic usage pattern is as follows. 

• TAB-z initiates the command entry sequence. The user is prompted for the name of 
a strategy (or rule) to invoke. The user will be prompted for inputs according to the 
formal argument list of the chosen rule or strategy. 

• To supply a value for an argument, the user has the choice of either entering text in 
the minibuffer, or selecting a region of text in the prover’s Emacs buffer, either by a 
mouse selection or any other means that sets point and mark. 

• A typed minibuffer text argument is terminated by a CR (return/entry) in the usual 
way. For a text region selection, TAB-, (TAB key followed by comma) causes the text 
region to be grabbed and added to the list of strategy arguments. 

• Quotes are added automatically to selected text but not to typed text because it 
might contain numbers or other constants. The user repeats the text entries or region 
selections until all required arguments have been supplied. 
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• If there are &optional arguments, the user is prompted for these as well and may 
enter them using the same methods. Optional argument keywords are not typed. 
Entering a null string in the minibuffer for an optional argument selects its default 
value. 

• Entering a for any optional argument causes the remaining optionals to be skipped 
and will proceed to the &rest argument phase if such an argument exists. Otherwise, 

terminates argument entry. A TAB-; (TAB-semicolon) typed after a region selec- 
tion has the same effect of moving to the next phase. 

• Rest argument entry proceeds for as many values as the user wishes to supply. 

• Entering the string “\” (single backslash character) discards the last argument and 
rolls back to the previous one. 

• Argument entry may be terminated at any time in the fooptional or forest phases by 
supplying the value in the minibuffer. Typing TAB-. (TAB-period) after a region 
selection has the same effect. 

• After the desired sequence of arguments has been gathered, the completed rule or 
strategy command is sent to the prover. 

This sequence may be abandoned at any point before completion using C-g and the partially 

constructed command will be deleted from the end of the Emacs buffer. 

6.2 Proof Maintenance Utilities 

Several functions are available to assist with proof maintenance activities. 

• Maintaining PVS proofs sometimes requires replaying previous proofs after chang- 
ing one or more theories, then editing failed steps embedded deep within the tree 
structure of commands. TAB-y is a utility to assist in finding the correct proof 
node in the Emacs buffer Proof, which is created by various commands such as 
M-x edit -proof. Position the cursor at the beginning of a proof label such as 
tan_increasing_imp . 3 . 2 . 2 in the prover buffer *pvs*. The label will be parsed 
and the cursor moved to the buffer Proof at the first step of the branch determined 
by the label. It is also possible to use labels found in prover messages such as: 

This completes the proof of tan_increasing_imp . 3 . 2 . 2 . 

The period at the end of the line will be recognized as punctuation rather than a part 
of the label and thus discarded by the label parser. 

• The interactive Emacs Lisp function M-x expand-strategy-steps allows a user to 
“expand” the strategy steps of a proof file, provided no proof is in progress. The user 
will be prompted for a proof file name. Each rule in the proof file is checked against 
a list of base rules found in the core PVS distribution. Any strategy name not found 
there is appended with a “$’ character so that it becomes a nonatomic command, 
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causing the next proof attempt to expand it into steps found only in the core rule 
base. A backup file of the original proofs is saved in a . sprf version of the proof file. 
Finally, the revised proof file is installed to make it current. 

This feature can be used for several purposes: 

- It allows proofs to be developed using domain-specific strategies for increased 
productivity then converted to a portable form using only core proof rules. 

— It allows proofs to be rerun without strategies to confirm that no unsoundness 
has been introduced by the strategies. 

— It allows users to create personal strategies for proof development, even highly 
speculative ones, knowing that proofs can be easily purged of nonstandard com- 
mands should the strategies be later discarded or abandoned. 

• The interactive Emacs Lisp function M-x restore-strategy-steps allows a user to 
restore the strategy steps found in a previously saved .sprf file. The current .prf 
file is simply replaced by the .sprf file. This function may not be invoked while a 
proof is in progress. The restored proof file is installed to make it current. 

6.3 Other Emacs Extensions 

Other Emacs features and TAB key assignments are provided for miscellaneous purposes. 

• A feature of interest to both strategy writers and users is a quick way to restore the 
prover’s state after a Lisp error is detected. TAB-] (right bracket) enters the Lisp 
command (restore) to return the prover to its previous state. 

• As seen earlier, several commands require the user to embed parameters in control 
strings using the percent (%) character. This causes a problem when installing edited 
proofs because of the well-formedness checking performed by the PVS install-proof 
function. In particular, % characters are interpreted as PVS comment characters, 
which can cause some expressions to fail the balance checks. 

To avoid this problem by suppressing the string balance checks, we have added an 
alternative function called install-proof ! . After editing a proof, a user may invoke 
install-proof ! using the (modified) key binding C-x C-s, while the regular version 
of install-proof is still available using C-c C-i or C-c C-c. 
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Chapter 7 


Prelude Extensions 


PVS allows users to extend the prelude with additional theories to support widely useful 
deductions. Manip takes advantage of this feature by loading a prelude extension library on 
start-up. In particular, the theory extra_real_props is added to enrich the standard pre- 
lude theory real_props. The extra lemmas are thereby made available to Manip strategies 
in a transparent manner; users need take no actions to make these lemmas visible. In fact, 
they need not even be aware of their existence and can simply use the strategies without 
concern for how additional facts are obtained. 

7.1 Overview of extra_real_props 

Prelude extensions may be loaded within PVS using M-x load-prelude-library. This 
operation is also callable as an Emacs Lisp function. Manip has an Emacs Lisp start-up file 
called pvs-prover-manip.el, which is loaded by the user’s ‘.pvsemacs’ file. The following 
excerpt shows how the prelude extension is loaded. 

;; The Prelude extension library adds lemmas needed by various strategies. 

; ; Extension files are kept in a version-specific subdirectory. Library 
; ; loading needs to run on a hook because library is unloaded during a 
; ; change-context operation. 

(add-hook 'change-context-hook 
’ (lambda () 

(load-prelude-library pvs-prover-manip-version-subdir) ) ) 

The extension is reloaded on every context change operation within PVS because of the 
data structure resetting performed during a context change. 

The extension theory itself is merely a collection of lemmas that closely resemble those 
found in theory real_props. 

U Contains extra properties about reals needed by the formula 
U manipulation strategies in package Manip. Can be seen as an 
*/.*/. extension of the real_props theory in the prelude. 

extra_real_props : THEORY 
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BEGIN 


°/°L Same variable declarations as real_props in the prelude: 

w, x, y, z: VAR real 

nOw, nOx, nOy, nOz: VAR nonzero_real 

nnw, nnx, nny, nnz: VAR nonneg_real 

pw, px, py, pz: VAR posreal 

npw, npx, npy, npz: VAR nonpos_real 

nw , nx , ny , nz : VAR negreal 

< Variations on real_props lemmas > 

END extra_real_props 

Extension lemmas adhere to real_props conventions as much as possible. This includes 
variable names as well as lemma names. Proofs for all the lemmas are contained within the 
Manip package. 

Most of the extension lemmas exist to provide more general versions of real_props 
lemmas, that is, the types of their variables are more inclusive. For example, a real_props 
lemma might require certain variables to be strictly positive or negative. Its extension analog 
might relax the type to the nonzero reals by using conditional expressions. Typically this 
makes the extension versions less useful as rewrite rules, but offers advantages for the sorts 
of interaction performed using our strategies. 

Relaxing variable types in some instances means abandoning rewrite rules written in 
the form of IFF expressions and casting them as implications instead. Again, this makes 
sense for the types of interactive strategies they are intended to serve. 

7.2 Selected Extension Lemmas 

The prelude contains the following lemmas for canceling factors in equalities: 
both_sides_timesl : LEMMA (x * nOz = y * nOz) IFF x = y 

both_sides_times2 : LEMMA (nOz * x = nOz * y) IFF x = y 

The canceled terms must be nonzero for these equivalences to hold. By weakening the 
relation to implication, we can allow the canceled terms to be arbitrary reals, as is done in 
the following extension lemmas used by the mult -by strategy. 

both._sides_timesl_imp : LEMMA x = y IMPLIES x * w = y * w 

both._sides_times2_imp : LEMMA x = y IMPLIES w * x = w * y 

For inequalities, the corresponding prelude lemmas differentiate on the canceled term 
being strictly positive or negative. 

both._sides_times_pos_lel : LEMMA x * pz <= y * pz IFF x <= y 

both._sides_times_pos_le2 : LEMMA pz * x <= pz * y IFF x <= y 
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both._sides_times_neg_lel : LEMMA x * nz <= y * nz IFF y <= x 

both._sides_times_neg_le2 : LEMMA nz * x <= nz * y IFF y <= x 

Again, introducing an implication form allows the types in extension lemmas to include 
zero. 

both._sides_times_pos_lel_imp : LEMMA x <= y IMPLIES x * nnw <= y * nnw 

both._sides_times_pos_le2_imp : LEMMA x <= y IMPLIES nnw * x <= nnw * y 

both._sides_times_neg_lel_imp : LEMMA y <= x IMPLIES x * npw <= y * npw 

both._sides_times_neg_le2_imp : LEMMA y <= x IMPLIES npw * x <= npw * y 

The following prelude lemmas allows us to eliminate divisions by multiplying both sides 
of an inequality by a positive or negative quantity. 

div_mult_pos_ltl : LEMMA z/py < x IFF z < x * py 

div_mult_pos_lt2 : LEMMA x < z/py IFF x * py < z 

div_mult_neg_ltl : LEMMA z/ny < x IFF x * ny < z 

div_mnlt_neg_lt2 : LEMMA x < z/ny IFF z < x * ny 

For occasions where the divisor could be any nonzero real, we provide extension lemmas 
that rewrite into conditional expressions. 

div_mult_pos_neg_ltl : LEMMA 

z/nOy < x IFF IF nOy > 0 THEN z < x * nOy ELSE x * nOy < z ENDIF 
div_mult_pos_neg_lt2 : LEMMA 

x < z/nOy IFF IF nOy > 0 THEN x * nOy < z ELSE z < x * n 0y ENDIF 
Prelude cancellation lemmas also adhere to the positive-negative dichotomy. 
both._sides_times_pos_ltl : LEMMA x * pz < y * pz IFF x < y 

both._sides_times_pos_lt2 : LEMMA pz * x < pz * y IFF x < y 

both._sides_times_neg_ltl : LEMMA x * nz < y * nz IFF y < x 

both._sides_times_neg_lt2 : LEMMA nz * x < nz * y IFF y < x 

Generalizing them for nonzero reals also introduces conditional expressions. 

both_sides_times_pos_neg_ltl : LEMMA 

IF nOz > 0 THEN x * nOz < y * nOz ELSE y * nOz < x * nOz ENDIF IFF x < y 
both_sides_times_pos_neg_lt2 : LEMMA 

IF nOz > 0 THEN nOz * x < nOz * y ELSE nOz * y < nOz * x ENDIF IFF x < y 
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The mult-cases strategy generates case analyses for relations on products. To carry 
this out for arbitrary reals requires more complex lemmas than the prelude provides. Several 
extension lemmas have been introduced for this purpose. They are much more complicated 
than related prelude lemmas and have no direct analogs. An example follows. 

lt_times_lt_anyl : LEMMA 

IF w = 0 OR x = 0 

THEN 0 < y AND 0 < z DR y < 0 AND z < 0 

ELSIF w > 0 IFF x > 0 

THEN (y > 0 IFF z > 0) AND 

(abs(w) <= abs(y) AND abs(x) < abs(z) OR 
abs(w) < abs(y) AND abs(x) <= abs(z)) 

ELSIF y > 0 IFF z > 0 
THEN true 

ELSE abs(w) >= abs(y) AND abs(x) > abs(z) OR 

abs(w) > abs(y) AND abs(x) >= abs(z) 

END IF 

IMPLIES w * x < y * z 

A few additional extension lemmas were needed to fill in gaps left by real_props. The 
lemmas below add cases omitted from similar prelude lemmas. 

div_cancel4: LEMMA x = y/nOz IFF x * nOz = y 

zero_times4: LEMMA 0 = x * y IFF x = 0 OR y = 0 

times_div_cancell : LEMMA (nOz * x) / nOz = x 

times_div_cancel2 : LEMMA (x * nOz) / nOz = x 

Finally, a few extension lemmas were included merely to correct inconsistent naming in 
certain real_props lemmas. They are simple renamings of existing lemmas. 

div_mult_pos_gtl : LEMMA z/py > x IFF z > x * py 

div_mult_pos_gt2 : LEMMA x > z/py IFF x * py > z 

div_mult_neg_gtl : LEMMA z/ny > x IFF x * ny > z 

div_mult_neg_gt2 : LEMMA x > z/ny IFF z > x * ny 
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Chapter 8 

Aids for Strategy Writing 


For users wishing to develop their own prover strategies, our package provides support in 
two ways. First, higher-order strategies and extended expressions reduce the need for low- 
level coding. Second, a set of Lisp utility functions is available for use once the package is 
loaded. 

8.1 Defining New Strategies 

Invocation strategies are useful as building blocks for more specialized strategies that users 
might need for particular circumstances. Extended expressions can support an alternative 
to the more code-intensive strategy-writing style that requires accessing the data struc- 
tures (CLOS objects) representing PVS expressions. The invocation strategies can make 
writing lightweight strategies more accessible to users without a deep background in Lisp 
programming. 

Consider a simple example. We wish to automate a specialized type of backward chaining 
process. Suppose a consequent formula exists having the form f (el) <= f (e2) for two 
expressions e\ and e 2. If / is monotonic and we know we can prove that e\ < e2, this would 
suffice to establish the consequent formula. So we would like to back-chain on this goal to 
produce the new goal el <= e2. The following strategy definition accomplishes this task 
by applying the pattern matching features. 

(defstep backchain-leq (fnum) 

(let ((case-step 

‘(invokes (case "7,2 <= 7,3") (? ,fnum "@f%li (°/„2*) <= 7,1 (7,3*)")))) 
(branch case-step ((assert) (skip)))) 

"Backchain on inequality in FNUM for monotonic function." 
"~7,Backchaining on inequality in formula "A") 

The pattern recognizes the desired inequality form for an arbitrary function and extracts 
the embedded arguments. A case rule invocation is constructed using these expressions. 
Of the two goals produced by the case rule, one is simplified using assert, while the other 
is the main branch left for the user to continue. 
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8.2 Support Functions 


Several Common Lisp functions defined in this package might be of use to strategy writers. 
They are used to access PVS data structures and perform other routine but frequently 
needed chores. 

get-equalities [ Function ] 

get-equalities returns a list of formula numbers for all antecedent equalities found in the 
current sequent. 


get-relations fnums [ Function ] 

Collect the formula numbers for all the relational formulas in the current sequent, omitting 
the case of the /= operator. 

map-f nums-arg fnums [Function] 

Use map-f nums-arg to map fnums into a list of concrete formula numbers, converting the 
symbols +, — , * and formula labels as needed. 

extract-fnums-arg fnums [Function] 

This utility extracts a list of formula numbers from an input that could include either 
extended expressions or conventional formula numbers. 


map-term-nums-arg tnums [Function] 

Use map-term-nums-arg to map tnums into a list of concrete term numbers, converting the 
symbol * and special form (~ . . .) as needed. 

manip-get-f ormula fnum [Function] 

manip-get-f ormula retrieves from the current goal the PVS data object corresponding to 
the formula specified in fnum. For an antecedent formula, the unnegated form is returned. 
The object returned is a CLOS object instance belonging to whatever class corresponds to 
the top-level PVS expression. 

percent-subst pattern values [Function] 

Textual substitution of template variables %1, . . . , %n, as discussed in Section 5.1, is per- 
formed by percent-subst using the list of values provided. Ideally, the number of elements 
in list values should equal n, the number of template variables. 

percent-to-regexp-pattern pattern [Function] 

This function maps a pattern written in the pattern language, i.e., strings involving text 
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field designators, into a regular expression suitable for matching and collecting substrings. 
The resulting regular expression may to be passed to the Lisp function excl : match-regexp 
(under the Allegro implementation) to carry out pattern matching and obtain a multiple- 
value outcome. 

eval-ext-expr expr-spec [ Function } 

Extended expression specifications are evaluated by this function. It returns a list of expres- 
sion descriptors, each of which is a structure containing the values <expr string> , <f num> 
and <CL0S objectx Some descriptors will not have meaningful values for each component. 
The value nil is supplied in such cases. 

build- instan-cmd cmd descriptors [ Function } 

An instantiated command is constructed by this utility function. Substitutions for all special 
symbols are performed and a fully instantiated command is returned as the function’s value. 

try-justification name try-just [ Function ] 

Generate a step using TRY that tries to prove a justification branch using try-just and 
backtracks on failure. 
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Chapter 9 

Examples 


We now present in full several proofs that make use of the Manip package strategies. The 
following definition and lemmas are taken from the NASA Langley trigonometry library [12], 
in particular, from the theory trig_approx. They are concerned with various properties of 
the sine power series (refer to equation (1.2) on page 2). 

sin_term(a) (i) : real = (-l)'(i-l) * a~(2*i-l)/factorial(2*i-l) 

sin_term_nonzero : LEMMA 0 /= a IMPLIES sin_term(a) (n) /= 0 

sin_term_next : LEMMA sin_term(a) (n+1) = 

sin_term(a) (n) * -1 * a*a / ((2*n+l) * 2*n) 

sin_terms_alternate : LEMMA 0 < a IMPLIES (sin_term(a) (n+1) < 0 IFF 

sin_term(a) (n) > 0) 

sin_terms_decr : LEMMA 0 < a AND a <= PI/2 IMPLIES 

abs(sin_term(a) (n)) > 2 * abs (sin_term(a) (n+1) ) 

Annotated proofs of the four lemmas appear in the following sections. 

9.1 Proof of Lemma sin_term_nonzero 

Lemma sin_term_nonzero is a simple property of the sin_term function. 
sin_term_nonzero : 


T IT FORALL (a: real, n: posnat) : 0 /= a IMPLIES sin_term(a) (n) /= 0 

Rerunning step: (SKOSIMP*) 

Repeatedly Skolemizing and flattening, 
this simplifies to: 
sin_term_nonzero : 

{-l} sin_term(a! 1) (n! 1) = 0 
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{1} 0 = all 


Rerunning step: (EXPAND "sin_term") 

Expanding the definition of sin_term, 
this simplifies to: 
sin_term_nonzero : 

{-1} (-1) ~ (nil - 1) * a! 1 ~ (2 * nil - 1) / factorial (2 * nil - 1) = 0 


[1] 0 = all 

We see that formula -1 could be simplified to a 2n ~ l = 0, from which we can deduce that 
a = 0. First we eliminate the division with cross-mult. 

Rerunning step: (CROSS-MULT) 

Multiplying both sides of selected formulas by LHS/RHS divisor (s) , 
this simplifies to: 
sin_term_nonzero : 

{-1} (-1) ~ (nil - 1) * a!l (2 * nil - 1) = 0 * factorial(2 * n!l - 1) 


[1] 0 = all 

Sometimes the prover will simplify 0 * x to 0, but in this case it is retained. We can 
force this reduction using equate. A location reference retrieves the right side of formula -1, 
which is then rewritten to 0. The justification step is proved automatically using (grind). 

Rerunning step: (EQUATE (! -1 R) "0" T) 
factorial rewrites factorial(2 * n!l - 1) 

to 2 * (factorial(2 * nil - 2) * nil) - factorial(2 * n!l - 2) 

Equating two expressions and replacing, 
this simplifies to: 
sin_term_nonzero : 

{-1} (-1) ~ (nil - 1) * all ~ (2 * nil - 1) = 0 


[1] 0 = all 

Now we have an equality of the form x * y = 0, which can be broken into cases 
by mult-cases. The branch involving (— 1)" _1 is simplified away by the strategy using 
(assert) . 

Rerunning step: (MULT-CASES -1) 

Analyzing cases for the relation in formula -1, 
this simplifies to: 
sin_term_nonzero : 
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{-1} all ~ (2 * nil - 1) = 0 


[1] 0 = all 

Rerunning step: (USE "nzreal_exp") 
Using lemma nzreal_exp, 
this simplifies to: 
sin_term_nonzero : 

{-1} all ~ (2 * nil - 1) /= 0 
[-2] all ~ (2 * nil - 1) = 0 


[1] 0 = all 

Rerunning step: (ASSERT) 

Simplifying, rewriting, and recording with decision procedures, 

Q.E.D. 

The remainder of the proof is handled by appealing to a prelude lemma to reduce the 
exponentiation term. 

9.2 Proof of Lemma sin_term_next 

Lemma sin_term_next is another simple property of the sin_term function, where term 
i + 1 is written as an expression involving term i. It should be provable by expanding 
functions and simplifying. Turning (grind) loose on this lemma, though, leads to some 
unproductive deductions. We need to proceed more deliberately. 

sin_term_next : 


fl) FORALL (a: real, n: posnat) : 
sin_term(a) (n + 1) = 

sin_term(a) (n) * -1 * a * a / ((2 * n + 1) * 2 * n) 

Rerunning step: (SKOSIMP*) 

Repeatedly Skolemizing and flattening, 
this simplifies to: 
sin_term_next : 


fl) sin_term(a! 1) (n! 1 + 1) = 

sin_term(a ! 1) (n ! 1) * -1 * a!l * all / ((2 * n!l + 1) * 2 * n!l) 

As before, we begin by eliminating the division operation. 

Rerunning step: (CROSS-MULT) 

Multiplying both sides of selected formulas by LHS/RHS divisor (s) , 
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this simplifies to: 
sin_term_next : 


{1} 2 * (sin_term(a! 1) (1 + n!l) * nil) + 

4 * (sin_term(a! 1) (1 + n!l) * nil * n!l) 

= -1 * (sin_term(a ! 1) (n ! 1) * all * all) 

After cross-multiplying, we find that the prover has applied the multiplicative distribu- 
tivity property, as it usually does. We prefer to undo this action and can do so using 
the factor strategy. After factoring all terms on the left side, the resulting expression is 
protected from future distribution by wrapping in an application of the identity function. 
Setting optional argument id? to T requests this action. 

Rerunning step: (FACTOR 1 L * T) 

Extracting common factors from additive terms of selected expressions, 
this simplifies to: 
sin_term_next : 


{1} sin_term(a! 1) (1 + n!l) * n!l * id(2 + 4 * n!l) = 
-1 * (sin_term(a! 1) (n! 1) * a!l * all) 

Rerunning step: (EXPAND "sin_term") 

Expanding the definition of sin_term, 
this simplifies to: 
sin_term_next : 


{1} id(2 + 4 * n! 1) * 

(((-1) ~ n!l * all ~ (1 + 2 * nil)) / factorial(l + 2 * nil)) 

* n ! 1 

-1 * 

((-1) ~ (n!l - 1) * all (2 * n!l - 1) / factorial(2 * nil - 1) * 
all 
* all) 

We would like to cross-multiply again. On the right-hand side, though, the division is 
embedded too deeply. We use permute-mult to reposition this factor at the right end of 
the product (currently the third factor from the end). 

Rerunning step: (PERMUTE-MULT 1 R -3 R) 

Permuting factors in selected expressions, 
this simplifies to: 
sin_term_next : 


{1} id(2 + 4 * n!l) * 
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(((-1) ~ n!l * all ~ (1 + 2 * nil)) / factorial(l + 2 * n!l)) 

* n ! 1 

-1 * all * all * 

((-1) ~ (n!l - 1) * all (2 * n!l - 1) / factorial(2 * n!l - 1)) 

After this maneuver, cross-multiplication will eliminate all remaining divisions. Then 
it will be in a form that (grind) can handle to finish off the proof. Note that this step 
and the previous one can be handled automatically by the Field strategies of Munoz and 
Mayero [11]. 

Rerunning step: (CROSS-MULT) 

Multiplying both sides of selected formulas by LHS/RHS divisor (s) , 
this simplifies to: 
sin_term_next : 


{1} (factorial^ * nil - 1) * id(2 + 4 * n!l) * (-1) ~ n!l * 
all ~ (1 + 2 * nil)) 

* n! 1 

-1 * 

(factorial(l + 2 * nil) * (-1) ~ (n!l - 1) * all (2 * n!l - 1) * 
a! 1 
* all) 

Rerunning step: (GRIND) 

factorial rewrites factorial(2 * nil - 1) 

to 2 * (factorial (2 * n!l - 2) * nil) - factorial^ * nil - 2) 
id rewrites id(2 + 4 * n!l) 
to 2 + 4 * n! 1 

expt rewrites expt((-l), n!l) 
to (-1) * expt((-l), n!l - 1) 
rewrites (-1) "nil 
to (-1) * expt((-l), n!l - 1) 
expt rewrites expt(a!l, 2 * n!l - 1) 
to all * expt(a!l, 2 * n!l - 2) 
expt rewrites expt (all, 2 * n!l) 

to all * (all * expt(a!l, 2 * n!l - 2)) 
expt rewrites expt (all, 1 + 2 * n!l) 

to a!l * (all * (all * expt(a!l, 2 * n!l - 2))) 
rewrites all (1 + 2 * n!l) 

to a!l * (all * (all * expt(a!l, 2 * n!l - 2))) 
factorial rewrites factorial(2 * n!l) 

to 4 * (factorial(2 * nil - 2) * nil * nil) - 

2 * (factorial(2 * nil - 2) * nil) 

factorial rewrites factorial(l + 2 * n!l) 

to 4 * (factorial(2 * nil - 2) * n!l * nil) - 

2 * (factorial(2 * n!l - 2) * nil) 

+ 
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(8 * (factorial(2 * nil - 2) * n ! 1 * n ! 1 * n ! 1) - 
4 * (factorial (2 * nil - 2) * n!l * nil)) 
rewrites (-1) ~ (n!l - 1) 
to expt((-l), (n!l - 1)) 
rewrites a! 1 ~ (2 * n! 1 - 1) 
to all * expt(a!l, 2 * n!l - 2) 

Trying repeated skolemization , instantiation, and if-lifting, 

Q.E.D. 

9.3 Proof of Lemma sin_terms .alternate 

Lemma sin_terms_alternate claims that successive terms in the series have alternating 
signs. Some basic reasoning about inequalities will suffice to show this. 

sin_terms_alternate : 


{1} FORALL (a: real, n: posnat) : 

0 < a IMPLIES (sin_term(a) (n + 1) < 0 IFF sin_term(a) (n) > 0) 

Rerunning step: (SKOSIMP*) 

Repeatedly Skolemizing and flattening, 
this simplifies to: 
sin_terms_alternate : 

{-1} 0 < all 


{1} (sin_term(a! 1) (n! 1 + 1) < 0 IFF sin_term(a! 1) (n! 1) > 0) 

Rerunning step: (REWRITE "sin_term_next") 

Found matching substitution: 
n: posnat gets n!l, 
a : real gets all, 

Rewriting using sin_term_next , matching in *, 
this simplifies to: 
sin_terms_alternate : 

[-1] 0 < all 


{l} (-1 * (sin_term(a! 1) (n! 1) * a!l * all) / (4 * (n!l * n!l) + 2 * n!l) 

< 0 

IFF sin_term(a! 1) (n! 1) > 0) 

We will need the fact that a 2 is positive, so we pause now to derive it. While there are 
library lemmas to introduce this fact, we can easily obtain it by using mult-ineq to square 
both sides of formula -1. 

Rerunning step: (MULT-INEQ -1 -1) 

Multiplying terms from formulas -1 and -1 to derive a new inequality, 


53 



this simplifies to: 
sin_terms_alternate : 

{-1} 0 * 0 < a! 1 * all 

[-2] 0 < all 


[1] (-1 * (sin_term(a! 1) (n! 1) * all * all) / (4 * (n!l * n!l) + 2 * n!l) 

< 0 

IFF sin_term(a! 1) (n! 1) > 0) 

Rerunning step: (GROUND) 

Applying propositional simplification and decision procedures, 
this yields 2 subgoals: 
sin_terms_alternate . 1 : 

{-I} -1 * (sin_term(a! 1) (n! 1) * a!l * all) / (4 * (n!l * n!l) + 2 * n!l) < 

0 

{-2} 0 < all * all 
[-3] 0 < all 


{1} sin_term(a! 1) (n! 1) > 0 

The (ground) step split IFF into two implications. On the current branch, we can start 
by eliminating division. 

Rerunning step: (CROSS-MULT -1) 

Multiplying both sides of selected formulas by LHS/RHS divisor(s), 
this simplifies to: 
sin_terms_alternate . 1 : 

{-1} -1 * (sin_term(a! 1) (n! 1) * a! 1 * all) < 

0 * (4 * (n!l * n!l) + 2 * nil) 

[-2] 0 < all * a! 1 
[-3] 0 < all 


[1] sin_term(a! 1) (n! 1) > 0 

It is apparent that if we divide formula -1 by —a 2 , we will reduce it to the conclusion. 
Using isolate-mult, we carry out this division, making sure to notify the strategy that 
the divisor is a strictly negative term. 

Rerunning step: (ISOLATE-MULT -1 L 2 -) 

Dividing by factors to isolate a term in formula -1, 
this simplifies to: 
sin_terms_alternate . 1 : 

{-1} -1 * all * all < 0 

{-2} 2 * ((0 / (-1 * (all * all))) * nil) + 

4 * ((0 / (-1 * (all * all))) * n! 1 * nil) 

< sin_term(a ! 1) (n ! 1) 
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[-3] 0 < all * all 
[-4] 0 < all 


{1} sin_term(a! 1) (n! 1) > 0 
Rerunning step: (ASSERT) 

Simplifying, rewriting, and recording with decision procedures, 

This completes the proof of sin_terms_alternate . 1 . 

Simplification using (assert) was sufficient to complete that branch of the proof. The 
other branch is proved in an identical manner. 

sin_terms_alternate . 2 : 

{-1} sin_term(a! 1) (n! 1) > 0 
{-2} 0 < all * all 
[-3] 0 < all 


{I]- -1 * (sin_term(a ! 1) (n ! 1) * a!l * all) / (4 * (n!l * n!l) + 2 * n!l) < 

0 

Rerunning step: (CROSS-MULT 1) 

Multiplying both sides of selected formulas by LHS/RHS divisor(s), 
this simplifies to: 
sin_terms_alternate . 2 : 

[-1] sin_term(a! 1) (n! 1) > 0 
[-2] 0 < all * a! 1 
[-3] 0 < all 


{I]- -1 * (sin_term(a! 1) (n! 1) * all * all) < 

0 * (4 * (n!l * n!l) + 2 * nil) 

Rerunning step: (ISOLATE-MULT 1 L 2 -) 

Dividing by factors to isolate a term in formula 1, 
this simplifies to: 
sin_terms_alternate . 2 : 

{-1} -1 * all * all < 0 

{-2} sin_term(a! 1) (n! 1) > 0 
[-3] 0 < all * a! 1 
[-4] 0 < all 


{1} 2 * ((0 / (-1 * (all * all))) * nil) + 

4 * ((0 / (-1 * (all * all))) * n! 1 * nil) 

< sin_term(a ! 1) (n ! 1) 

Rerunning step: (ASSERT) 

Simplifying, rewriting, and recording with decision procedures, 
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This completes the proof of sin_terms_alternate . 2 . 

Q.E.D. 

9.4 Proof of Lemma sin_terms_decr 

Lemma sin_terms_decr makes a statement about the relative magnitudes of successive 
terms in the power series for sine. Its proof was sketched in Figure 1.1 (refer to lemma (1.1) 
on page 1). Following is the full proof of this lemma. 

sin_terms_decr : 


fll FORALL (a: real, n: posnat) : 

0 < a AND a <= PI / 2 IMPLIES 
abs (sin_term(a) (n)) > 2 * abs (sin_term(a) (n + 1)) 

Rerunning step: (SKOSIMP*) 

Repeatedly Skolemizing and flattening, 
this simplifies to: 
sin_terms_decr : 

{-1} 0 < all 

{-2} all <= PI / 2 


{1} abs(sin_term(a! 1) (n! 1)) > 2 * abs(sin_term(a! 1) (n! 1 + 1)) 

Rerunning step: (REWRITE "sin_term_next") 

Found matching substitution: 
n: posnat gets n!l, 
a : real gets all, 

Rewriting using sin_term_next , matching in *, 
this simplifies to: 
sin_terms_decr : 

[-1] 0 < all 

[-2] all <= PI / 2 


fll abs (sin_term(a ! 1) (n ! 1) ) > 

2 * 

abs(-l * (sin_term(a! 1) (n! 1) * all * all) / 

(4 * (n!l * n!l) + 2 * nil)) 

Here we find the absolute value of an expression containing both multiplications and 
division. If they were all multiplications, we could apply the lemma abs_mult repeatedly 
to distribute the abs function over all the factors. We elect to take this route by first 
converting the embedded division into multiplication by a reciprocal using recip-mult ! . 
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Note the use of the location reference (! 1 R (-> "abs") 1) to identify the desired 
subexpression. The shorter alternative (! 1 R 2 1) achieves the same effect, but the for- 
mer would be more resilient in the face of small changes to the expressions. Another 
alternative would be ( ! 1 (-> "abs" "/")), which picks the desired instance of the abs 
function from the two possibilities and burrows down to the division operator. 

Rerunning step: (RECIP-MULT! (! 1 R (-> "abs") 1)) 

Converting division in selected terms to multiplication by reciprocal, 
this simplifies to: 
sin_terms_decr : 

[-1] 0 < all 

[-2] all <= PI / 2 


{1]- abs (sin_term(a ! 1) (n! 1) ) > 

2 * 

abs((-l * (sin_term(a ! 1) (n ! 1) * all * all)) * 
(1 / (4 * (n ! 1 * n ! 1) + 2 * n!l))) 

Rerunning step: (APPLY (REPEAT (REWRITE "abs.mult") ) ) 
Applying 

(REPEAT (REWRITE "abs.mult") ) , 
this simplifies to: 
sin_terms_decr : 

[-1] 0 < all 

[-2] all <= PI / 2 


{1} abs(sin_term(a! 1) (n! 1)) > 

2 * 

(abs(-l) * (abs(sin_term(a! 1) (n! 1)) * abs(a!l) * abs(a!l)) * 
abs((l / (4 * (n!l * n!l) + 2 * n!l)))) 

Now we notice common terms on both sides of the inequality and decide to cancel them. 
First we must reorder some factors so the common term is on the right. 

Rerunning step: (PERMUTE-MULT 1 R 3 R) 

Permuting factors in selected expressions, 
this simplifies to: 
sin_terms_decr : 

[-1] 0 < all 

[-2] all <= PI / 2 


{1} abs (sin_term(a ! 1) (n ! 1) ) > 

2 * abs(-l) * abs(a!l) * abs(a!l) * 
abs((l / (4 * (n!l * n!l) + 2 * nil))) 
* abs (sin_term(a ! 1) (n! 1) ) 
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Logically, we should be able to cancel now, but the cancellation strategy requires both 
sides to have the same form, i.e., x * y in this case. So we first multiply the left side by 1 
using op-ident, after which we may invoke cancel. 

Rerunning step: (OP-IDENT 1 L 1*) 

Applying identity operation to rewrite selected expression, 
this simplifies to: 
sin_terms_decr : 

[-1] 0 < all 

[-2] all <= PI / 2 


{If (1 * abs (sin_term(a ! 1) (n ! 1) ) > 

2 * abs(-l) * abs(a!l) * abs(a!l) * 
abs ( (1 / (4 * (nil * n!l) + 2 * n!l))) 

* abs (sin_term(a ! 1) (n ! 1) ) ) 

Rerunning step: (CANCEL 1) 

Canceling terms from both sides of selected formulas, 
this yields 2 subgoals: 
sin_terms_decr . 1 : 

[-1] 0 < all 

[-2] all <= PI / 2 


fl> 1 > 

2 * abs(-l) * abs(a!l) * abs(a!l) * 
abs ( (1 / (4 * (n ! 1 * n!l) + 2 * nil))) 

Having canceling the common factors, we may now expand abs and simplify. 

Rerunning step: (EXPAND "abs") 

Expanding the definition of abs, 
this simplifies to: 
sin_terms_decr . 1 : 

[-1] 0 < all 

[-2] all <= PI / 2 


{ 1 > 1 > 

2 * 

((1 / (4 * (nil * n ! 1) + 2 * nil)) * 

IF all < 0 THEN -all ELSE all END IF 

* IF all < 0 THEN -a!l ELSE all END IF 

* — 1 ) 

Rerunning step: (ASSERT) 

Simplifying, rewriting, and recording with decision procedures, 
this simplifies to: 
sin_terms_decr . 1 : 
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[-1] 0 < all 

[-2] all <= PI / 2 


{1} 1 > 2 * ((1 / (4 * (n ! 1 * nil) + 2 * nil)) * —1 * all * all) 

Again, we find an embedded division we would like to move to the outside so we can 
apply cross-mult. 

Rerunning step: (PERMUTE-MULT 1 R 2 R) 

Permuting factors in selected expressions, 
this simplifies to: 
sin_terms_decr . 1 : 

[-1] 0 < all 

[-2] all <= PI / 2 


{1} 1 > 2 * —1 * all * a! 1 * (1 / (4 * (n!l * n!l) + 2 * nil)) 

Rerunning step: (CROSS-MULT 1) 

Multiplying both sides of selected formulas by LHS/RHS divisor(s), 
this simplifies to: 
sin_terms_decr . 1 : 

[-1] 0 < all 

[-2] all <= PI / 2 


{1} 1 * (4 * (n ! 1 * n ! 1) + 2 * nil) > 2 * ( — 1 * a !l * all) 

We have manipulated formula 1 close to the form we need. Now we turn our attention 
to the antecedents. To establish the conclusion it suffices to show that n(2n + 1) > a 2 . 
Because n is a positive integer, we must have a 2 < 3. But a < ir/2, so a 2 is bounded by 
7r 2 /4, which numerically is around 2.467. 

We begin by squaring both sides of formula -2 to derive a new relationship between a 2 
and 7r 2 . 

Rerunning step: (MULT-INEQ -2 -2) 

Multiplying terms from formulas -2 and -2 to derive a new inequality, 
this simplifies to: 
sin_terms_decr . 1 : 

{-1} all * all <= (PI / 2) * (PI / 2) 

[-2] 0 < all 

[-3] all <= PI / 2 


[1] 1 * (4 * (n! 1 * n ! 1) + 2 * nil) > 2 * (—1 * all * all) 

Next we need to bring in facts about the numerical value of n. The upper bound PI_ub 
will be of use. 
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Rerunning step: (TYPEPRED "PI") 
Adding type constraints for PI, 
this simplifies to: 
sin_terms_decr . 1 : 


{-1} 

PI >= 0 


{-2} 

PI > 0 


{-3} 

PI >= PI_lb 


{-4} 

PI <= PI_ub 


[-5] 

all * all <= (PI / 2) 

* (PI / 2) 

[-6] 

0 < all 


[-7] 

all <= PI / 2 


| 

[1] 

1 * (4 * (n! 1 * n ! 1) 

+ 2 * n ! 1) > 2 * ( — 1 * all * all) 


Rerunning step: (EXPAND "PI_ub") 
Expanding the definition of PI_ub, 
this simplifies to: 
sin_terms_decr . 1 : 


[-1] 

PI > 

= 0 




[-2] 

PI > 

0 




[-3] 

PI > 

= PI_ 

lb 



{-4} 

PI < 

= 315 

/ 100 



[-5] 

all 

* all 

<= (PI / 

2) 

* (PI / 2) 

[-6] 

0 < 

a! 1 




[-7] 

1 

all 

<= pi 

/ 2 



[1] 

1 * 

(4 * 

(n! 1 * n! 

1) 

+ 2 * nil) > 2 * ( — 1 * all * all) 


Squaring the upper bound on t: in formula -4 gives us the last inequality we need to 
complete the chain of reasoning. 

Rerunning step: (MULT-INEQ -4 -4) 


Multiplying terms from formulas -4 and -4 to derive a new inequality, 
this simplifies to: 
sin_terms_decr . 1 : 

{-1} PI * PI <= (315 / 100) * (315 / 100) 

[-2] PI >= 0 

[-3] PI > 0 

[-4] PI >= PI_lb 

[-5] PI <= 315 / 100 

[-6] all * all <= (PI / 2) * (PI / 2) 

[-7] 0 < all 

[-8] all <= PI / 2 


[1] 1 * (4 * (n ! 1 * n ! 1) + 2 * nil) > 2 * (—1 * all * all) 

Having derived a numerical bound on a 2 indirectly through n 2 /4 gives the prover enough 
information to see that the conclusion holds. 
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Rerunning step: (ASSERT) 

Simplifying, rewriting, and recording with decision procedures, 

This completes the proof of sin_terms_decr . 1 . 

sin_terms_decr . 2 : 

[-1] 0 < all 

[-2] all <= PI / 2 


{1} abs (sin_term(a ! 1) (n ! 1) ) > 0 
{2]- (abs (sin_term(a ! 1) (n ! 1) ) > 

2 * 

(abs((l / (4 * (n!l * n!l) + 2 * n!l))) * abs(-l) * abs(a!l) * 
abs (all)) 

* abs (sin_term(a ! 1) (n ! 1) ) ) 

Rerunning step: (USE "sin_term_nonzero") 

Using lemma sin_term_nonzero , 
this simplifies to: 
sin_terms_decr . 2 : 

{-1} 0 /= all IMPLIES sin_term(a! 1) (n! 1) /= 0 

[-2] 0 < all 

[-3] all <= PI / 2 


[1] abs(sin_term(a! 1) (n! 1)) > 0 

[2] (abs(sin_term(a! 1) (n! 1)) > 

2 * 

(abs((l / (4 * (n!l * n!l) + 2 * n!l))) * abs(-l) * abs(a!l) * 
abs (all)) 

* abs (sin_term(a! 1) (n! 1) ) ) 

Rerunning step: (GRIND NIL : REWRITES ("abs")) 
abs rewrites abs (sin_term(a ! 1) (n ! 1) ) 
to -sin_term(a! 1) (n! 1) 

Trying repeated skolemization , instantiation, and if-lifting, 

This completes the proof of sin_terms_decr . 2 . 

Q.E.D. 

The remainder of the proof is concerned with a side condition spawned by the earlier 
cancellation step. It can be completed easily using conventional proof rules. 

Again, it is worth noting that several steps in this proof can be handled more automat- 
ically by the Field 11] strategies. 
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Chapter 10 


Discussion 


The following sections discuss the results we have obtained thus far. 

10.1 Related Work 

Shankar [15] sketches an approach to the enhanced use of rewrite libraries for arithmetic 
simplification. While these methods are certainly helpful, we believe they need to be aug- 
mented by proof interaction of the sort we advocate. 

Tactic-based proving has been used extensively in major interactive provers such as 
HOL [8], Isabelle [14] and Coq [9]. Although most of this activity has been devoted to 
low-level automation, there also have been higher level tactics developed. An example is a 
semi-decision procedure for reals [11], which had been developed originally for Coq and was 
recently ported to PVS. 

Several researchers have developed PVS strategy packages for specialized types of prov- 
ing. Examples include a mechanization of the TRIO temporal logic [1], a proof assistant for 
the Duration Calculus [17], and the verification of simple properties for state-based require- 
ments models [5]. A notable example is Archer’s account of the TAME effort [2], which has 
a good discussion on developing PVS strategies for timed automata models and using them 
to promote “human-style” theorem proving. 

ACL2 [10] supports tactic-based proving through a Common Lisp framework and a 
notion of events. While ACL2 normally conducts fully automatic proofs, it also contains a 
mechanism for low level interaction. Included are commands for simple navigation within 
expression trees using actions such as “move forward one term.” Other commands enable 
the current term thus reached to be used in various ways. 

What differentiates our work from these other efforts is an emphasis on interactive proof, 
rich features for extracting terms from the working sequent, and flexible mechanisms for 
exploiting such terms. Many tactic approaches stress control issues, often neglecting the 
equally important data issues. Only by placing nontrivial term-access facilities at the user 
interface can the full potential of interactive tactics be realized. 
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10.2 Conclusions 


The arithmetic package has been used experimentally at NASA Langley and made available 
to the PVS user community. Various lemmas from Langley’s trigonometry library [12] 
have been reproved as test cases, some of which were highlighted in Chapter 9. A new 
real-analysis library under development is currently using the Manip package. Further 
experimentation is underway to gauge effectiveness and suggest new strategies. 

Tactic-based theorem proving still holds substantial promise for automating domain- 
specific reasoning. In the case of PVS, much effort has gone into developing decision pro- 
cedures and rewrite rule capabilities. While these are undoubtedly valuable, there is still 
ample room for other advances, particularly those that can leverage the accumulated knowl- 
edge of experienced users of deduction systems. Such users are well poised to introduce the 
wide variety of deductive middleware needed by the formal methods and computational 
logic communities. Our tools and techniques aim to further this goal. 

10.3 Future Plans 

Future activities will focus on refining the techniques and introducing new strategy packages 
for additional domains. One domain of interest is reasoning about sets, especially finite sets. 
We expect that ideas from the arithmetic strategies can be readily adapted. 

Several other topics are potential areas for enhancement: 

• Higher-level arithmetic strategies 

• Better coverage for the syntactic features of the PVS language 

• New types of extended expressions 

• Proof file annotations to document extended expression accesses 
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